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POSIX  DELTA  DOCUMENT  FOR  THE 
NEXT-GENERATION  COMPUTER  RESOURCES  (NGCR) 
OPERATING  SYSTEMS  INTERFACE  STANDARD  BASELINE 

(VERSION  4) 


1.  INTRODUCTION 

The  objective  of  the  Next-Generation  Computer  Resources  (NGCR)  Program  is  to  standardize 
Navy  mission-critical  computer  interfaces  and  computer  component  interfaces.  With  these  standardized 
intedaces,  industry  will  be  better  able  to  provide  computing  resources  that  meet  Navy  needs.  The 
interface  standards  are  to  be  widely  available  (i.e.,  non-proprietary)  and,  if  possible,  widely  used  within 
industry. 

The  NGCR  Operating  Systems  Standards  (OSS)  is  one  of  the  sets  of  standards  essential  to  the 
timely  and  cost  effective  acquisition  of  most  of  the  next  generation  of  mission-critical  computing  systems 
for  the  Navy.  NGCR  OSS  assists  the  Navy  in  efficiently  providing  a  wide  range  of  performance,  oon^atble 
computing  services,  and  functionality  levels. 

The  primary  objective  of  the  NGCR  Operating  Systems  Standards  Worthing  Group  (OSSWG)  will 
be  the  selection,  from  commercial  standards,  of  a  set  of  interface  standards  for  a  family  of  distributed 
operating  systems  applicable  to  a  complete  spectrum  of  Navy  combatant  use  and  other  mission-critical 
use.  If  these  standards  are  not  available  or  adequate,  a  standard  will  be  devetoped  in  conjunction  with 
industry. 

1.1  SCOPE 

The  scope  of  this  document  includes  the  NGCR  OSSWG  Operational  Concept  Document  (NUWC 
Technical  Document  f  0168,  Febmary  1993)  and  all  available  documents,  draft  and  final,  from  the  family  of 
the  Portable  Operating  System  Interfaces  (POSIX)  standards,  which  have  been  selected  as  the  NGCR 
baseline.  In  addition,  the  documents  from  the  IEEE  working  groups  1201,  1224.  1238,  1326,  1327, 
1328, 1351,  and  1353  were  examined. 

1.2  PURPOSE 

The  purpose  of  this  document  is  to  evaluate  how  effectively  each  Operating  System  Interface 
(OSIF)  requirement,  as  defined  by  the  Operational  Concept  Document,  is  addressed  by  the  POSIX 
standards.  By  evaluating  each  OSIF  requirement,  the  OSSWG  will  be  able  to  determine  as  to  how  well  the 
POSIX  standards  currently  meet  the  Navy's  needs. 

The  findings  of  this  document  will  form  a  basis  for  identifying  enhancements  to  POSIX. 
Comparing  the  POSIX  standards  and  OSIF  requirements  can  lead  to  one  of  several  findings: 

Requirement  is  fulfilled  by  POSIX, 

Requirement  is  unnecessary  and  can  be  discarded. 

Requirement  is  fulfilled  by  SAFENET, 

Requirement  was  previously  considered  and  discarded  by  POSIX, 

Requirement  is  nice  to  have,  but  not  really  needed  or  worth  working  toward. 

Requirement  is  loo  far  out"  and  it  would  be  premature  to  standardize  at  this  time. 

Requirement  is  a  must  ("got  to  have")  and  must  be  included  even  if  POSIX  does  not  include  it, 

POSIX  includes  this  useful  feature  but  rt  is  not  a  requirement. 

From  the  list  of  requirements  being  pursued,  an  approach  to  take  them  into  POSIX  must  be 
determined,  explaining  the  concepts,  rationale,  and  interfaces  required. 
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If  a  necessary  requirement  conflicts  with  POSIX,  then  the  OSSWG  will  develop  a  strategy  for 
meeting  this  requirement.  Thte  document  will  eventually  become  a  primary  input  into  a  Military  Handbook 
for  an  OSIF.  All  requirements  not  fulfilled  by  POSIX  standards  or  some  other  open  standard  will  be 
addressed  in  the  Military  Han(ftx>ok. 

1.3  TERMINOLOGY 

Precise  and  consistent  use  of  terms  has  been  attempted  throughout  the  document.  The 
following  verb  phrases  are  used  in  all  NGCR  documents  to  indicate  where  and  to  what  degree  individual 
constraints  apply: 

"SHALL  PROVIDE"  indicates  a  requirement  for  the  operating  system  interface  to  provide 
interface(s)  with  prescribed  capabilKies. 

"SHALL  SUPPORT"  indicates  a  requirement  for  the  operating  system  interface  to  provide 
interface(s)  with  prescribed  capabilities  or  for  the  operating  system  interface  definers  to  demonstrate  that 
the  capability  can  be  constructed  from  operating  system  interfaces. 

1.4  DOCUMENT  ORGANIZATION 

This  document  was  originally  organized  to  reflect  the  evolutionary  analysis  process  utilized  by  the 
OSSWG  to  determine,  for  each  OSSWG  requirement,  the  extent  to  which  POSIX  fulfilled  that 
requirement,  the  overall  irniMrtance  of  the  requirement  being  fulfilled  by  standard  interfaces,  and  the 
OSSWG  approach  to  definirtg  standard  interfaces  to  fulfill  all  critical  requirements.  However,  this 
o^anization  was  considered  awkward,  at  best,  for  document  maintenance  and  reader  comprehension. 
Since  the  original  analysis  process  is  long  since  completed,  it  is  no  longer  necessary  for  the  document  to 
retain  this  structure.  Therefore,  starting  with  version  4,  the  document  has  been  reorganized  more  along 
the  lines  of  a  reference  guide.  The  historical  information  on  the  analysis  process  can  always  be  found  in 
earlier  document  versions. 

The  current  structure  of  the  document  is  centered  around  section  3,  where  each  operating 
system  interface  requirement  from  the  Operational  Concept  Document  (OCD)  is  presented,  grouped  into 
the  same  service  classes  and  in  the  same  order  as  defined  in  the  OCD.  For  a  requirement  which  is 
completely  fulfilled  by  POSIX,  this  section  indicates  which  POSIX  interfaces  fulfill  the  requirement,  and 
provides  an  explanation  of  how  this  is  accomplished  where  it  isn't  completely  obvious.  For  a  requirement 
which  is  either  partially  or  totally  unfulfilled  by  POSIX,  this  section  descnljes:  the  extent  of  the  delta  (partial 
or  no  POSIX  coverage) ;  the  extent  of  change  necessary  for  POSIX  to  fulfill  the  requirement  (modification 
or  insertion);  and  the  importance  of  ultimately  standardizing  interfaces  which  meet  the  requirement 
(essential,  highly  desirable,  may  be  deferred,  should  be  reevaluated).  Furthermore,  for  those  unfulfilled 
requirements  classified  essential  or  highly  desirable,  alternatives  for  achieving  standardization  (if  rrwre 
than  one),  and  OSSWG  recommendations  are  presented.  This  section  combines  all  delta  information 
related  to  each  requirement  in  one  centralized  place. 

Because  of  the  rapidly  evolving  nature  of  POSIX,  especially  the  continuous  reorganization  of 
unapproved  drafts,  section  3  does  not  attempt  to  cite  references  to  specific  chapters,  paragraphs,  pages, 
or  lines  in  POSIX  documents.  Instead,  POSIX  interfaces  are  described  here  using  the  names  commonly 
used  to  refer  to  such  interfaces  and  associated  POSIX  document  (PAR)  numbers.  Because  this 
document  serves  not  only  as  an  OSSWG  working  document,  but  as  a  reference  document  for  potential 
NGCR  Operating  System  users,  ^pendix  A  lists  for  each  OSSWG  requirement,  in  tabular  form,  detailed 
paragraph  references  to  the  versions  of  POSIX  documents  baselined  in  section  2,  as  well  as  selected 
tabular  infonnation  from  section  3. 

Each  unfulfilled  OSSWG  requirement  is  coded,  both  in  section  3  and  Appendix  A,  with  a  ratirtg 
indicating  Its  significance  to  the  overall  NGCR  OS  interface  standardization  effort;  A  rating  of  "a"  indicates 
that  standardization  of  interfaces  which  meet  the  requirement  is  essential;  a  rating  of  "b"  indicates  that 
standardization  of  interfaces  which  meet  the  requirement  is  highly  desirable;  a  rating  of  "c"  indicates  that 
fulfilling  this  interface  requirement  can  be  deferred  to  a  later  date;  a  rating  of  "d"  indicates  that  the  OSSWG 
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should  re-evaluate  the  need  for  standardized  IrHerfaces  fulfilling  this  requirement.  All  requirements  with  a 
rating  of  "a”  or  "b*  are  termed  "significant  unfulfilled  requirements",  a  status  which  trig^rs  an  OSSWG 
recommendation  for  fulfilling  the  requirement  as  soon  as  possible. 

Section  4,  the  Big  6  Discussion,  offers  an  overview  of  the  POSIX/OSSWG  delta  with  re^^ect  to  six 
major  technology  areas  considered  important  to  the  NGCR  program  in  general.  This  provides  an  hisightful 
alternative  viewpoint  on  the  nature  of  the  delta  and  how  POSIX  can  be  expected  to  support  these 
technology  areas. 

In  conclusion.  Section  5  summarizes  the  findings  of  this  document. 
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3.  DETAILED  ANALYSIS  OF  POSIX  DELTAS  BY  REQUIREMENT 

This  section  presents  each  operating  system  interiace  requirement  from  the  OSSWG  Operational 
Concept  Document  (OCD),  grouped  according  to  the  same  service  classes  and  in  the  same  order  as 
defined  in  the  OCD.  For  a  requirement  which  is  completely  fulfilled  by  POSIX,  this  section  indicates  which 
POSIX  interfaces  fulfill  the  requirement,  and  provides  an  explanation  of  how  this  is  accomplished  where  it 
isnt  completely  obvious.  For  a  requirement  which  is  either  partially  or  totally  unfulfilled  by  POSIX,  this 
section  descrit^s:  the  extent  of  the  delta  (partial  or  no  POSIX  coverage);  the  extent  of  change  necessary 
for  POSIX  to  fulfill  the  requirement  (modification  or  insertion);  and  the  importance  of  ultimately 
standardizing  interfaces  which  meet  the  requirement  (essential,  highly  desirable,  may  be  deferred,  should 
be  reevaluated).  Furthermore,  for  those  unfulfilled  requirements  classified  essential  or  highly  desirable 
(the  so-called  "significant  unfulfilled  requirements"),  alternatives  for  achieving  standardization  (if  more  than 
one),  and  OSSWG  recommendations  are  presented. 

This  section  contains  frequent  references  to  interfaces  and  capabilities  from  the  POSIX  1003.1 
and  1003.4  standards,  as  weil  as  the  POSIX  Pi 003.4a  draft  standard.  Each  of  these  documents  provides 
a  C  language  binding  to  the  referenced  interfaces  and  capabilities.  OSSWG  understands  that  the  POSIX 
1003.5  standard,  the  POSIX  PI 003.20  draft  standard,  and  the  Ada  LRM  provide  an  Ada  language  binding 
to  exactly  the  same  set  of  interfaces  and  capabilities;  however,  due  to  the  nature  of  the  bindings  and  the 
Ada  language  itself,  identical  interfaces  and  capabilities  do  not  typically  have  the  same  nomenclature  in 
the  Ada  language  bindings  as  in  the  C  language  bindings.  A  further  complication  is  that  Pi  003.20  is 
currently  undergoing  a  change  from  "thin"  to  "thick*  binding  format.  Therefore,  this  version  of  the  Delta 
Document  will  not  attempt,  in  this  section,  to  consistently  mention  1003.5  or  Pi  003.20  interlaces 
whenever  1003.1, 1003.4,  or  1003.4a  interfaces  are  cited  as  fulfilling  or  partially  fulfilling  a  requirement; 
this  will  be  undertaken  in  the  next  version  once  Pi 003.20  has  stabilized  in  its  "thick"  binding  format. 
Appendix  A  lists  the  applicable  interfaces  and  capabilities  in  both  the  C  language  binding  documents  and 
the  Ada  language  binding  documents. 

There  is  a  table  presented  at  the  end  of  each  service  class  with  columns  marked  "Requirement", 
"Covered",  "POSIX  Delta",  and  "Unfulfilled  Requirements  Rating."  The  first  column  contains  the  OSSWG 
requirement  number.  The  second  column  assesses  coverage  as  "Yes",  "No",  or  "Partially.*  The  third 
column  indicates  the  extent  of  the  POSIX  Delta  and  contains  one  of  the  following  assessments;  "None", 
"Modification",  or  "Insertion."  "Modification"  means  that  a  modification  to  existing  POSIX  interfaces  would 
fulfill  the  OSSWG  requirement;  "Insertion*  means  that  a  modification  is  not  sufficient  and  that  a  larger 
change  such  as  insertion  of  new  interfaces  would  probably  be  needed  to  fulfill  the  OSSWG  requirement. 
All  OSSWG  requirements  marked  as  partially  or  not  covered  are  referred  to  as  "unfulfilled  requirements." 
The  fourth  column  can  contain  a  dash  or  one  of  the  letters  a,  b,  c,  or  d.  A  rating  of  "a*  indicates  that 
standardization  of  interfaces  which  meet  the  requirement  is  essential;  a  rating  of  ”b"  indicates  that 
standardization  of  interfaces  which  meet  the  requirement  is  highly  desirable;  a  rating  of  "c"  indicates  that 
fulfilling  this  interface  requirement  can  be  deferred  to  a  later  date;  a  rating  of  *d”  indicates  that  the  OSSWG 
should  reevaluate  the  need  for  standardized  interfaces  fulfilling  this  requirement.  All  OSSWG 
requirements  with  a  rating  of  "a"  or  "b"  are  referred  to  as  "significant  unfulfilled  requirements",  a  status 
which  triggers  an  OSSWG  recommendation  for  fulfilling  the  requirement  as  soon  as  possible. 

3.1  GENERAL  REQUIREMENTS 

These  requirements  are  considered  too  high  level  to  be  covered  in  this  document. 

3.2  ARCHITECTURE  DEPENDENT  INTERFACES 

There  are  no  unfulfilled  requirements  for  service  class  2.  In  general,  POSIX  1003.1  and  1003.4 
support  service  class  2. 
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3.2.1  Non-NGCR  System  Interfaces 

Non-NGCR  System  Interfaces  are  met  by; 

1003.1  Process  Primitives 
1003.1  Input  and  Output  Primitives 

1003.4  Process  Primitives 

1003.4  Input  and  Output  Primitives 

1003.4  Shared  Memory 

1003.4  Message  Passing 
PI  003.1 2  Network  Interface 

The  OSIF  shall  support  rton-NGCR  based  systems  by  providing  a  subset  of  its  services  to  those 
systems.  The  subset  of  service  requests  from  non-NQCR  based  systems  includes  download,  initialize, 
start,  resource  sharing,  process  to  process  message  communication,  and  ability  to  pass  operational  status 
information. 

The  non-NGCR  system  may  issue  service  requests  over  non-NGCR  or  NGCR  network  interfaces. 
The  NGCR  network  interfaces  include  FUTUREBUS-t-,  SAFENET,  (see  the  operational  concept 
document  (OCO),  Paragraph  20.8.1.1).  The  non-NGCR  network  interfaces  include  (but  are  not  limited  to) 
VME,  MULTIBUS,  TCP/IP,  RS232,  RS422  and  1553B  (see  OCD  paragraph  20.8.2.3). 

POSIX  does  not  provide  explicit  interfacing  to  non-NGCR  networks.  However,  POSIX  can  support 
interfacing  to  non-NGCR  networks  given  that  the  term  '‘support*  allows  for  hardware  to  be  added  to  the 
non-NGCR  network  interface,  and  software  to  be  added  to  both  NGCR  and  non-NGCR  systems.  The 
application  implementation  of  the  additional  hardware  and  software  will  allow  the  ability  to  service  non- 
NGCR  system  service  requests. 


Requirements  Coverage  Summary 


Requirement 

Covered 

POSIX  Delta 

Unfulfilled 

Requirements 

Rating 

2.1 

Yes 

None 

- 

3.3  CAPABILITY  AND  SECURITY  INTERFACES 

Computer  security  requirements  permeate  the  engineering  process  and  development 
environment  of  a  system.  The  level  of  security  depends  on  the  criticality  of  the  system  application  and 
total  environment  (e.g.,  physical,  procedural,  operational,  communication,  and  computer  controls).  With 
this  in  mind,  the  challenge  for  the  OSSWG  and  POSIX  security  working  groups  has  been  to  create  an 
interface  standard  that  does  not  preclude  meeting  the  trusted  computer  systems  evaluation  criteria 
(TCSEC)  (OoO-STO-5200.28)  B3  or  A1  class  requirements.  The  approach  used  to  develop  the  POSIX 
security  standards  (P1003.1e  and  PI  003.2c)  is  similar  to  the  OSSWG  security  approach  where  the  focus 
is  only  on  the  application  program  interfaces  and  commands  of  the  operating  system  with  respect  to 
security,  not  implementation  or  assurance  details.  However,  in  addressing  some  of  the  non  interface 
security  concepts,  the  POSIX  subcommittee  has  tailored  these  concepts  into  a  POSIX  philosophy  for 
uniformity  and  portability,  and  documented  them  in  the  appropriate  PI 003.1  e  and  PI  003.2c  appendixes. 
The  POSIX  subcommittee  has  been  very  effective,  thus  far,  in  addressing  the  nonsupported,  security- 
related  concepts  without  mandating  a  specific  design  or  architecture.  Those  areas  that  are  not  supported 
by  PI  003.1  e  are  discussed  in  its  appendix  B,  the  unsupported  security  section.  This  allows  a  contractor 
design  and  development  flexibility,  while  still  providing  the  basic  conformity  and  interface  consistency 
four^  In  standards.  The  POSIX  Distributed  Security  Study  Group  (1003.22),  was  convened  in  early  1992 
to  examine  seojrity  standardization  issues  which  fall  outside  the  domain  of  PI 003.1  e  and  PI 003.2c. 
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They  will  be  assessing  existing  work  in  this  area  and  analyzing  the  potential  for  standardization  of 
distit)uted  secur^  work,  and  will  draft  a  Guide  similar  to  P1 003.0  to  this  effect. 

As  stated,  some  requirements  are  not  interface-specific  security  issues  but,  rather,  system- 
unique  security  issues.  In  this  case,  the  interpretation  of  the  TCSEC  requirements  in  conjuration  with  the 
system  security  policy  would  take  precedence  over  any  aspects  of  the  PI  003.1  e  arxl  PI  003.2c  interface 
standards.  Unfulfilled  requirements  will  need  to  be  analyzed  by  the  system  engineering  office  within  the 
context  of  the  system  being  developed.  Each  requirement  should  be  studied  to  determine  its 
applicability  to  the  system  and,  if  required,  the  suitability  of  the  contractor's  design  in  context  of  the 
system's  security  policy.  Therefore,  the  capability  to  fulfill  these  requirements  should  be  deferred  until  a 
need  is  determined  and  how  they  may  be  best  implemented  to  satisfy  the  system's  security  policy. 

Of  the  24  OSSWG  requirements,  21  are  addressed  by  the  P1003.1e  and  P1003.2C  standards 
(see  Requirements  Ckiverage  Summary).  [Note:  The  P1003.le  standard  addresses  all  24  OSSWG 
security  requirements  in  different  ways.  Some  of  the  requirements  are  in  the  interface  section,  while 
others  are  addressed  in  appendix  B  as  non  interface,  nonsupported  security  mechanisms.  The  OSSWG 
agrees  with  the  PI  003.6  standards  committee  on  this  format;  thus,  OSSWG  feels  the  committee  has 
sufficiently  addressed  the  OSSWG  requirements.] 

in  assessing  the  OSSWG  security  requirements,  it  was  determined  that  the  following 
requirements  are  not  addressed  by  the  Pi 003.1  e  or  Pi  003.2c  standards:  Object  Reuse  (3.17),  Tmsted 
Path  (3.23),  and  Trusted  Recovery  (3.24).  However,  some  of  these  requirements  are  within  the  scope  of 
PI  003.22,  and  while  they  constitute  implementation  concerns,  they  could  receive  attentr  in  the 
PI  003.22  Guide  to  the  POSIX  Security  Framework.  However,  the  1003.22  working  grou^  will  not 
produce  a  standard,  per  se,  but  rather  a  guide  to  distributed  security  issues.  Therefore,  it  is 
recommended  that  these  requirements  be  dropped  from  consideration  of  any  API  standard  approved  by 
the  NGCR  OSSWG. 


3.3.1  Audit  Data  Storage 

The  capability  and  security  interfaces  service  class  requirements  are  addressed  in  the  P1003.1e 
document.  This  OSSWG  requirement  is  covered  in  the  interface  portion  of  the  standard. 

3.3.2  Audit  Generation 

Refer  to  3.3.1. 

3.3.3  Audit  Record  Contents 

Refer  to  3.3.1. 

3.3.4  Audit  Data  Manipuiation 

Refer  to  3.3.1. 

3.3.5  Device  Labeis 

Refer  to  3.3.1. 
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3.3.6  Basic  DAC 

Refer  to  3.3.1 . 

3.3.7  DAC  Inclusion/Exclusion 

The  requirement  for  DAC  Inclusion/Exclusion  (3.7)  is  met  by  studying  the  functionality  of  the 
interiace,  but  the  document  does  not  provide  a  clear  discussion  of  exclusion. 

3.3.8  DAC  Propagation 

Refer  to  3.3.1. 

3.3.9  Labeling  of  Export  Channels 

Refer  to  3.3.1. 

3.3.10  Setting  Communication  Labels 

Refer  to  3.3.1. 


3.3.11  Identification  and  Authentication 

This  OSSWG  requirement  is  addressed  by  the  PlOOS.Ie  standard  in  appendix  B.  Even  though  it 
specifies  this  requirement  as  an  unsupported  security  mechanism,  the  standard  does  not  preclude 
satisfying  this  requirement;  this  requirement  is  addressed  in  DoD  Standard  5200.28. 

Note  that  1003.1  also  provides  interfaces  to  identify  and  to  irK|uire  about  the  identity  of  users. 


3.3.12  Labeling  of  Human  Readable  Output 

Refer  to  3.3.1 . 


3.3.13  Subject  and  Object  Labeling 

For  Subject  and  Object  Labeling  (3.13),  the  POSIX  definition  of  subjects  and  objects  is  very  broad 
and  may  not  provide  sufficient  detail  to  meet  B2  requirements  and  above.  However,  for  the  purpose  of  an 
interface  standard  this  should  be  acceptable  because  significant  depth  in  this  area  will  be  provided  by 
either  the  vendor  or  the  contractor  as  the  system  architecture  and  design  that  incorporate  the  interface 
standard  are  developed. 


3.3.14  Label  Contents 

Refer  to  3.3.1. 


3.3.15  MAC  Policy 

Refer  to  3.3.1. 
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3.3.16  MAC  Manipulation 

MAC  Manipulation  has  been  addressed  in  P1 003.1  e  and  Pi  003.2c,  while  the  manipulation  of 
labels  remains  a  non-programmatic,  non-interface  issue  dictated  by  the  security  policy. 

3.3.17  Object  Reuse 

This  unfulfilled  requirement  is  classified  as  "d*  (re-evaluate). 

Requirement:  The  OSIF  shall  provide  that  all  objects  are  sanitized  prior  to  allocation  to  a  user. 

Description  of  the  Delta:  Object  Reuse  is  rx>t  a  programmatic  interlace-related  requirement.  It  is  a 
requirement  between  a  user  terminal,  peripheral  hardware  elements,  and  the  operating  system's  trusted 
computing  base.  A  conforming  implementation  may  implement  a  strong  object  reuse  policy  without 
impacting  the  API  specified  by  the  standard. 

Recommendation:  The  requirement  will  be  levied  on  the  developers  through  the  TCSEC  when 
required;  thus,  no  further  action  is  recommended. 

3.3.18  User  Notification  of  Sensitivity  Labei 

Refer  to  3.3.11. 

3.3.19  Sensitivity  Label  Query 

Refer  to  3.3.11. 

3.3.20  System  Integrity 

Refer  to  3.3.11. 

3.3.21  Identification  of  Users  Based  on  Roles 

Refer  to  3.3.11. 


3.3.22  Least  Privilege 

Refer  to  3.3.1. 

3.3.23  Trusted  Path 

This  unfulfilled  requirement  is  classified  as  "d”  (re-evaluate). 

Requirement:  The  OSIF  shall  support  a  trusted  communication  path  between  the  user  and  the 
system,  activated  exclusively  by  the  user. 

Description  of  the  Delta:  The  trusted  path  requirement  is  not  a  programmatic  interface-related 
requirement.  It  is  a  requirement  between  a  user  terminal  and  the  operating  system's  trusted  computing 
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base.  It  will  be  addressed  in  the  Pi  003.22  Guide  to  the  POSIX  Security  FramewoiX,  which  will 
complemem  the  work  being  done  in  both  the  1003.0  and  1003.6  committees. 

Recomrrwndation:  The  requirement  will  be  ievied  on  the  developers  through  the  TCSEC  when 
required;  thus,  no  further  action  is  recommended. 

3.3.24  Trusted  Recovery 

This  unfuifiiled  requirement  is  ciassified  as  ‘cT  (re-evaluate). 

Requirement:  The  OSIP  shaii  provide  procedures  or  mechanisms  or  both  to  assure  that,  after  a 
discontinuity,  recovery  without  a  protection  compromise  is  obtained. 

Description  of  the  Delta:  This  is  not  an  programmatic  interface  related  requirement  but  a 
requirement  internal  to  the  trusted  computing  base  (TCB)  concerned  with  tnjsted  recovery  to  a  secure 
state  of  the  TCB  when  non  recoverable  failure  occurs.  It  will  be  addressed  in  the  PI  003.22  Guide  to  the 
POSIX  Security  Framework,  which  will  complement  the  work  being  done  in  both  the  1003.0  and  1003.6 
committees. 

Recommendation:  The  requirement  wiil  be  levied  on  the  developers  through  the  TCSEC  when 
required;  thus,  no  further  action  is  recommended. 
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3.4  DATA  INTERCHANGE  INTERFACES 

AppetxJix  B,  Rattonaie  and  Notes,  of  the  1003.1  indicates  that  the  POSIX  groups  felt  the  tesue  of 
data  format  should  be  addressed  in  1003.1.  1003.1/1003.5  does  not  yet  provide  a  standard  data 
interchange  interface,  nor  does  it  define  a  standard  format  for  the  data.  1224  is  deveioping  an  ASN.l 
(Abstract  Syntax  Notation  One)  APi.  A  notable  hole  in  the  1224  work  is  a  result  of  the  working  group 
decision  not  to  provide  interfaces  for  floating-point  data. 

A  non-POSIX  alternative  for  meeting  the  data  interchange  requirement  is  XDR  (External  Data 
Representation),  an  Internet  standard  (see  RFC1014).  XDR  is  well-established,  provides  a  relatively 
straight-forward  binding  to  PI  003.1 2,  is  capable  of  supporting  realtime  communication,  is  canonical,  has 
no  explicit  typing,  and  represents  arbitrary  data  structures  in  a  consistent,  well-documented  manner. 
However,  XDR  at  thte  t^  does  not  have  POSIX  or  ISO  support. 

Data  Interchange  Interfaces  are  necessary  to  support  the  Big  6  requirement  for  heterogeneity. 

One  aspect  of  the  Data  interchange  issue  arises  from  the  fact  that  the  various  hardware  and 
software  platforms  used  in  Navy  systems  represent  various  uncoordinated  data  types  being  passed 
between  many  systems.  These  systems  were  developed  on  essentially  the  same  computer  hardware,  at 
different  times,  by  different  vendors,  and  for  different  sponsors,  with  incremental  funding.  Most  of  these 
systems  were  developed  long  ago,  prior  to  any  formal  standardization  process,  and  were  designed  to 
perform  specific  tasks  that  were  not  always  integrated.  The  cost  of  ownership  of  this  wide  spectrum  of 
systems  is  inconsequential  compared  with  the  replacement  cost  of  upgrading  to  systems  that  have  a 
standardized  data  interchange.  Therefore,  an  interface  is  needed  to  support  the  required  "normalized" 
representations  of  data  interchanged  between  these  different  systems.  This  interface  would  provide 
standards  for  upgrading  these  older  systems  with  a  more  effective  approach. 

Likewise,  the  interface  would  provide  standards  for  combining  COTS  products  effectively, 
whether  or  not  the  products  originate  in  older  systems. 


3.4.1  Data  Interchange  Services  (Data  Format  Conversion) 

This  unfulfilled  requirement  is  classified  as  "a”  (essential). 

Requirement:  The  OSIF  shall  support  an  access  to  services  that  perform  data  conversion. 

Description  of  Delta:  P1351  and  P1353  have  developed  an  ASN.l  API.  However,  this  API  will 
not  support  floating-point  data.  ASN.l  is  already  an  ISO  standard.  It  is  canonical,  supports  explidt  typing, 
and  represents  arbitrary  data  structures  in  a  consistent,  well-documented  manner.  A  potential 
disadvantage  of  ASN.l  is  that  it  may  not  be  capable  of  supporting  realtime  systems 

Resolution  Altematives: 

1 .  Pursue  adding  floating-point  data  support  to  P1351  and  P1353. 

2.  Pursue  standardizing  XDR  within  POSIX. 

3.  Adopt  XDR  as  another  OSSWG-recommended  standard  (in  addition  to  POSIX). 

Recommendation:  Investigate  1 .  and  2.;  should  2.  fail,  pursue  3.  to  meet  realtime  requirements. 
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3.5  EVENT  AND  ERROR  INTERFACES 

In  general,  the  POSIX  standards  support  service  class  5  (Event  and  Error  Interfaces)  in  a 
mdimertary  way.  There  are  three  areas  that  are  not  complete: 

1.  Basically,  POSIX  provides  reactive  error  management  while  OSSWG  requires  proactive 
behavior.  Attempting  to  support  proactive  requirements  on  top  of  a  reactive  interface  will  result  In 
performance  penalties.  The  existing  (proactive)  services  are  highly-oriented  toward  providing  event 
services  (via  the  "signer  concept)  while  downplaying  error  reporting. 

2.  POSIX  currently  does  not  have  a  consistent  error  handling  strategy.  The  POSIX  workirrg 
groups  covering  cfistribution  are  beginning  to  develop  such  a  strategy. 

3.  POSIX  does  not  provide  adequate  coordination  and  recording  services. 

While  none  of  the  requirements  in  senr’ce  class  5  are  completely  satisfied  by  POSIX  interfaces,  an 
the  associated  OSSWG  requirements  remain  necessary  for  Navy  systems.  Given  that  the  OSSWG  wiU 
now  deal  only  with  APIs  for  the  OSIF,  requirement  5.1  becomes  deferred  for  errors,  since  the  error 
information  comes  from  sources  other  than  applications;  it  is  fulfilled  in  the  case  of  events  other  than 
errors. 


POSIX  signals  provide  a  useful  abstraction  for  managinjg  asynchronous  events  and  can  be  used 
to  coordinate  the  activities  of  processes.  In  particular,  signals  unify  the  following: 

-  synchronous  exceptions,  such  as  floating  point  overflow,  division  by  zero,  and  invalid  addresses 
or  instructions 

-  abortion  of  a  process  or  thread  of  control 

-  suspension  of  a  process 

•  time-outs  such  as  an  alarm  or  timer  expiration 

-  asynchronous  notification  from  one  process  or  another  of  an  application-specific  event  that 
demands  attention 

However,  precisely  because  they  are  so  all-encompassing,  signals  also: 

-  confuse  synchronous  traps  with  asynchronous  events 

-  can  be  aliased  in  confusing  ways 

-  can  be  lost 

•  are  unique  resources  which  cause  problems  when  various  independent  application  components 
are  integrated 

Conflicts  over  the  right  to  handle  a  signal  are  a  problem  for  the  Ada  njntime,  since  it  rer^ires  the  use  of 
certain  specific  signals,  and  it  is  not  something  a  user  can  ordinarily  be  expected  to  patch  up.  The  POSIX 
Ada  bindings  address  this  situation  by  denying  an  Ada  application  the  ability  to  handle  certain  signals 
which  are  expected  to  be  used  by  the  Ada  runtime  system.  This  still  leaves  the  need  for  intervention  if  an 
Ada  application  wants  to  use  a  C  language  library  that  depends  on  catching  the  same  signals  used  by  the 
Ada  nintlme  system. 


14 


N  AWC  AOWAR-941 09-70 


The  OSSWG  requirements  could  be  met  by  adding  new  interfaces  to  POSiX.  Existing  Merfaces 
do  not  need  to  be  modified  or  deleted.  However,  some  philosophical  views  and  assumptions  of  the 
P09X  community  (^er  considerably  from  the  OSSWG  conceptual  rrxxjel. 

Exwnples  are  access  to  hardware  interrupt  masks  and  error  logging.  Both  were  cited  as  'out  of 
scope*  by  the  POSIX  community. 

1003.4b  has  developed  interrupt  control  interfaces  which  fulfill  Requirement  5.5  arxl  corrtribute 
to  the  fulfillment  of  Requirement  5.2.  Due  to  hardware  dependencies,  it  may  not  be  appropriate  to 
Mempt  to  standardize  interfaces  for  masking4rnmasking  interrupts. 


Executive  Summary:  The  following  paragraphs  serve  as  an  explanation  and  summary  of 
section  3.5,  Event  and  Error  Interfaces,  and  section  3.11,  Reliability,  Adaptability,  and  Maintainability 
Interfaces.  While  these  two  service  classes  are  closely  related,  note  that  service  class  5  goes  beyond 
strictly  error  interfaces,  which  also  apply  to  service  class  1 1 ,  and  deals  more  broadly  with  events,  which 
may  or  may  not  be  related  to  errors.  The  thrust  of  this  summary  is  system  fault  and  error  management, 
which  is  concerned  with  the  error  aspects  of  service  class  5  atxf  with  service  class  1 1 .  Section  3.5  does, 
however,  also  discuss  events  in  detail. 

In  addition,  while  some  of  the  requirements  from  service  classes  5  and  1 1  deal  wtth  interfaces 
between  an  operating  system  and  entities  other  than  application  software,  this  summary  and  sections  3.5 
and  3.11  consider  satisfying  requirements  only  through  an  API.  The  discussion  of  other  types  of 
operatirtg  system  interfaces  is  deferred  at  this  time. 

In  general,  the  OSSWG  discovered  that  POSIX  provides  or  supports  little  in  the  way  of  interfaces 
for  service  classes  5  and  1 1  as  they  relate  to  system  fault  and  error  management.  (Sections  3.5  and  3.1 1 
discuss  the  deltas  between  what  the  OSIF  requires  and  what  POSIX  supplies  for  each  OSIF  requirement 
in  detail.)  Consequently,  the  OSSWG  considered  the  following  alternatives  to  resolve  the  deltas  between 
the  OSIF  requirements  and  POSIX: 

1.  Enhance  existing  POSIX  interfaces  to  include  this  capability.  System  fault  and  error 
management  is  rrot  generally  a  natural  extension  to  existing  POSIX  interfaces.  It  may  frt  as  new  work  under 
POSIX  1003.7,  system  administration. 

2.  Submit  a  new  POSIX  PAR  to  do  this  work.  POSIX  may  require  a  new  PAR  even  should  this 
work  be  done  under  1003.7.  A  substantial  body  of  existing  practice  is  available  for  system  fault  and  error 
management  in  current  military  tactical  systems  and  may  also  be  available  in  such  commercial  applications 
as  telephone,  medical,  and  banking  systems.  The  availability  of  people  to  do  this  work  may  well  be  the 
deciding  factor  in  providing  this  capability  in  POSIX.  People  would  probably  have  to  come  largely  from 
OSSWG  as  general  interest  in  the  POSIX  community  for  this  kind  of  activity  seems  to  be  low.  However, 
the  O^WG  should  also  contact  commercial  parties  where  interest  may  be  growing. 

3.  Mature  a  standard  outside  of  POSIX.  UNIX  International  (High  Availability  Investigative  Team), 
Open  Software  Foundation  (OSF),  and  X3T8  (Fault  Isolation)  have  efforts  that  might  fill  a  large  nurr^r  of 
the  current  deltas.  OSSWG  could  use  these  as  the  vehicles  to  mature  a  industry  standard  outside  of 
POSIX.  At  the  ^ropriate  time  a  new  PAR  could  be  pursued  in  POSIX. 

4.  Develop  a  new  military  standard.  This  is  a  less  acceptable  alternative  than  2,  although 
comparable  in  effort,  because  it  is  external  to  the  OSIF  baseline. 

5.  Levy  the  requirements  and  the  OSIF  general  requirements  (e.g.,  modularity,  extensibility, 
uniformity)  on  vendors  but  do  not  provide  a  standard  as  such.  This  alternative  relies  on  vendors  to 
develop  some  oomnrercial  existing  practice  in  this  area  on  which  to  potentially  standardize  at  a  later  date. 

The  OSSWG  recommends  at  this  time  that  a  standard  be  matured  outside  of  POSIX,  through  UNIX 
International,  OSF,  and  X3T8  as  appropriate.  Unfulfilled  OSIF  requirements  which  could  be  satisfied  by 
other  efforts  include: 
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3.5.1  Event  and  Error  Receipt 

3.5.2  Everit  and  error  distribution 

3.5.3  Event  and  error  management 

3.5.4  Event  logging 

3.11.1  Fsttiit  information  collection 

3.1 1 .2  Fault  information  request 

3.1 1 .3  Diagnostic  tests  request 

3.11.4  Diagnostic  tests  results 

3.11.5  Operational  status 

3.1 1 .6  Fault  detection  thresholds 

3.11.7  Fault  isolation 

3.11.8  Fault  response 

3.11.9  Reconfiguration 

3.1 1 .10  Enable/disable  system  component 

3.11.11  Performance  monitoring 

3.1 1 .12  Set  resource  utilization  limits 

3.1 1 .13  Resource  utilization  limits  violation 

The  OSSWG  recommends  satisfying  3.5.6,  Mask/Unmask  Interrupts  in  PI  003.4b  where  this  work 
has  alreac^  been  undertaken.  MaskAJnmask  Interrupts  is  net  provided  by  PI  003.4b  because  of  hardware 
dependencies  (classification  as  a  significant  unfuifilled  requirement  should  be  reconsidered.) 
ArMitionally,  some  minimal  functionality  can  be  achieved  for  requirements  3.11.3,  Diagnostic  Test 
Requests.  3.11.4,  Diagnostic  Test  Resuits,  3.11.5,  Operational  Status,  3.11.8,  Fault  Response,  3.11.9, 
Reconfiguration,  and  3.11.10,  Enable/Disable  System  Component  through  interface  service  devctl()  in 
PI  003.4b.  DevctiO  aiiows  standard  access  to  'non  standardized*  hardware  devices. 


3.5.1  Event  and  Error  Receipt 

This  unfulfilled  requirement  is  classified  as  "c”  (may  be  deferred). 

OSSWG  r^irement  5.1  is  partially  covered  by  POSIX.  While  the  event  interfaces  exist,  and  error 
interfaces  are  provided  for  individuai  processes,  there  are  no  error  coordination  or  distnbution  interfaces. 

Requirement:  The  OSIF  shall  support  the  receipt  and  coordination  of  event  and  error  information. 

Description  of  Delta:  This  requirement  refers  to  error  information  coming  into  the  OS  across  the 
OSIF  other  than  through  an  API  for  subsequent  distribution  according  to  requirement  3.5.2.  The  event 
receipt  part  of  this  requirement  is  met  by  the  POSiX  Signals  interface  and  the  interrupt  Control  interfaces 
in  P1003.4b. 

Recommendation:  For  error  receipt,  because  OSSWG  is  only  concerned  with  the  API  portion  of 
the  OSIF  at  this  time  and  for  most  applications  this  requirement  deals  with  parts  of  the  OSIF  other  than 
APIs,  this  requirement  delta  is  a  low  priority.  Monitor  and  participate  in  related  standards  efforts  at  UNIX 
International;  Open  Software  Foundation;  POSIX  Services  for  Reliable,  Available,  and  Serviceable 
Systems  group;  and  X3T8.  When  these  groups  develop  mature  standards,  move  appropriate  portions  of 
standards  into  POSIX. 


3.5.2  Event  and  Error  Distribution 

This  unfulfilled  recpiirement  is  classified  as  "a"  (essential). 

PI 003.4b  Interrupt  Control  specifies  that,  upon  occurrence  of  a  designated  interrupt,  a 
designated  process  or  thread  is  to  be  notified,  or  a  designated  user-written  Interrupt  Service  Routine  (ISR) 
is  to  be  executed  (or  both).  This  interrupt  control  capability,  in  conjunction  with  1003.1/l003.4/l003.4a 
signals,  would  provide  some  coverage  of  requirement  5.2  (distribution  of  event  and  error  information).  In 
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particuiar,  the  irtterrupt  control  mechanism  could  be  used  for  the  distribution  of  information  on  e^'ems  and 
errors  resulting  in  hardware  interrupts  (such  as  hardware  devk:e  errors).  However,  this  distribution 
mechanism  would  not  be  applicable  to  certain  operating  system  errors  (such  as  those  in  which  kernel  data 
structures  become  faulty). 

Another  possible  deficiency  in  the  coverage  of  requirement  5.2  is  the  fact  that  functions  return 
indication  of  only  a  single  error,  instead  of  all  errors  that  occur  during  function  processing. 

Requirement:  The  OSIF  shall  provide  for  the  selective  distribution  of  event  and  error  information. 

Descrfeition  of  Delta:  POSIX  1003.1  provides  for  the  distrtt)ution  of  events  through  signals.  T^le 
3-1  (1003.1)  lists  the  signals  that  all  POSIX  irrqilementations  must  support  and  Table  3-2  (1003.1)  lists 
those  signals  that  a  system  implementing  job  control  must  support.  However,  "an  implementation  may 
define  additional  signals  that  may  occur  in  the  system"  (1003.1).  For  particular  systems,  it  may  be 
significant  that  the  signals  defined  by  1003.1  and  1003.5  do  not  allow  for  any  user-defined  information, 
such  as  a  pointer  to  an  error  report,  to  be  passed  with  the  signal  and  do  not  queue  mult'^le  occurrences  of 
a  signal.  The  Signals  interface  is  enhanced  in  1003.4  with  the  addition  of  Queued  Signals,  and  all  signal 
types  are  extended  to  threads  in  P1003.4a.  The  1003.4  and  P1003.20  specificattons  altow  an  application 
to  reserve  a  range  of  signal  numbers  as  real-time  signals.  These  signals  may  pass  a  user-defined  value  or 
pointer  to  the  signal-catching  function.  In  addition  multiple  occurrences  of  real-time  signals  are  queued  for 
the  application  in  FIFO  order. 

POSIX  provides  for  the  distribution  of  errors  to  the  requesters  of  individual  functions.  Each 
function  specifies  which  errors  all  POSIX  implementations  must  detect  and  which  are  optional.  1003.1 
lists  the  possible  errors.  However,  "implementations  may  support  addKional  errors  not  iru:iuded  in  this 
clause,  may  generate  errors  included  in  this  clause  under  circumstances  other  than  those  descrft>ed  in 
this  clause,  or  may  contain  extensions  or  limitations  that  prevent  some  errors  from  occurring"  (paragraph 
2.4, 1003.1).  "If  more  than  one  error  occurs  in  processing  a  function  cali,  this  part  of  ISO/IEC  9945  does 
not  define  in  what  order  the  errors  are  detected;  therefore,  any  one  of  the  possible  errors  may  be 
returned"  (paragraph  2.4,  1003.1).  (CAN  THIS  APPROACH  BE  TOLERATED?]  In  addition,  realtime 
extensions  in  POSIX  1003.4b  provide  for  handling  of  interrupts.  In  1003.4b  the  occurrence  of  an 
interrupt  can  be  made  to  notify  a  process  or  thread,  or  start  the  execution  of  a  user-written  ISR  (or  both). 

The  OSIF  requires  that  all  possible  errors  be  available,  not  just  one  of  those  possible.  [AGAIN, 
CAN  THIS  BE  TOLERATED?]  It  also  rec^jires  that  there  be  a  means  for  coordinating  the  distribution  of 
errors,  as  for  exainple  to  a  single  process  responsible  for  error  analysis.  The  1003.4b  interrupt  control 
interface  enables  distrttxjtion  of  certain  errors,  namely  those  resulting  in  hardware  interrupts.  Besides  the 
fact  that  the  Pi  003.4b  Interrupt  Control  interface  can  deliver  only  hardware  interrupts  and  the  Signals 
interface  can  deliver  any  event  or  error  defined  by  the  system,  it  may  be  important  for  particular  systems  to 
note  another  difference  between  the  two  interfaces:  Interrupt  Control  has  distinct 
registration/deregistration  functions  for  each  interrupt  whereas  the  Signals  interlace  relies  on  signals  be 
sent  to  or  retrieved  by  the  proper  application  software. 

Recommendation:  The  OSSWG  recommends  continued  support  for  approval  of  the  PI  003.4b 
Interrupt  Control  interfaces  via  the  balloting  process. 

And,  to  completely  satisfy  this  requirement,  OSSWG  recommends  monitoring  and  participating  in 
related  standards  efforts  at  UNIX  International;  Open  Software  Foundation;  POSIX  Services  for  Reliable, 
Available,  and  Serviceable  Systems  group;  and  X3T8.  The  POSIX  Services  for  Reliable,  Available,  and 
Serviceable  Systems  group,  in  addition  to  proposing  new  interfaces,  may  suggest  modifications  to 
existing  interfaces,  such  as  reserving  a  set  of  real-time  signal  numbers  for  error  reporting.  When  these 
groups  develop  mature  standards,  move  appropriate  standards  into  POSIX. 


3.5.3  Event  and  Error  Management 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 


17 


NAWC  AOWAR-941 09-70 


Raquirement:  The  OSIF  shall  support  the  timely  delivery  of  interrupt  and  asynchronous  events  to 
system  components  and  shall  support  the  implementation  of  user-selectable  error  processing 
aRematives.  ARematives  shaR  include,  as  a  minimum,  fiRedng,  retry,  ignore,  and  accumulate  occurrences. 

Descrtotion  of  DeRa:  POSIX  does  make  special  provisions  for  the  timely  delivery  of  irtterrupts  and 
asynchronous  events  which  generate  interrupts  to  system  components;  Pi  003.4b  Interrupt  Control 
Interfaces  provide  for  process  or  thread  notRication  on  occurrence  of  an  interrupt  and/or  for  handling  the 
interrupt  via  an  Interrupt  Sen/ice  Routine  (ISR).  For  asynchronous  events  which  generate  signals, 
'Implementations  should  deliver  unblocked  signals  as  soon  after  they  are  generated  as  possible. 
However.  R  Is  difficuR  for  POSIX.  1  to  make  specific  requirements  about  this,  beyond  those  in  kill()  and 
sigprocmask().  Even  on  systems  with  prompt  delivery,  scheduling  of  higher  priority  processes  is  always 
likely  to  cause  delays'  (paragraph  B.3.3.1 .2. 1 003.  i ). 

Within  the  limits  discussed  under  requirement  3.5.2  (i.e.,  POSIX  does  not  provide  for 
coordination  in  the  distribution  of  events  and  errors),  some  user-selectable  error  processing  aRematives 
are  available.  Processes  can  mask  signals  (paragraph  3.3.1. 2,  1003.1).  Processes  can  also  choose 
among  three  types  of  actions  that  they  can  associate  wRh  a  signal:  a  defauR  action,  ignore,  and  a  signal 
catching  function  (paragraph  3.3. 1.3, 1003.1).  Retries  and  accumulatton  of  occurrences  would  then  be 
the  responsbility  of  the  individual  processes.  In  particular,  occurrences  of  a  particular  event  or  error  could 
not  be  collected  or  action  taken  on  behalf  of  several  processes  or  on  behaH  of  the  system  as  a  whole 
through  the  interface. 

Recommendation:  OSSWG  recommends  continued  support  for  approval  of  the  PI 003.4b 
Interrupt  Control  interfaces  via  the  balloting  process.  K  necessary,  OSSWG  recommends  rTX)nRoring  and 
partici^ting  in  related  standards  efforts  at  UNIX  International;  Open  Software  Foundation;  the  POSIX 
Services  for  Reliable,  Available,  and  Serviceable  Systems  group;  and  X3T8.  When  these  groups  develop 
mature  standards,  move  appropriate  standards  into  POSIX. 


3.5.4  Event  Logging 

This  unfutfilied  requirement  is  classified  as  'a'  (essential). 

Requirement  5.4,  event  logging,  is  not  currently  supported  by  POSIX. 

Requirement:  The  OSIF  shall  support  logging  events  to  application-defined  storage.  The  types 
of  events  and  event  sources  shall  be  dynamically  selectable/deselectable. 

Description  of  DeRa:  POSIX  does  not  support  logging  events.  The  1003.4  working  group 
considers  this  to  be  a  system  administration  issue. 

Recommendation:  OSSWG  recommends  monRoring  and  participating  in  related  standards  efforts 
at  UNIX  International;  Open  Software  Foundation;  the  POSIX  Services  for  Reliable,  Available,  and 
Serviceable  Systems  group;  and  X3T8.  When  these  groups  develop  mature  standards,  move  appropriate 
standards  into  POSIX. 


3.5.5  Enable/Disable  Interrupts 

This  requirement  is  directly  met  by  the  Interrupt  Control  interfaces  in  PI  003.4b.  These  interfaces 
provide  for  mutual  exclusion  between  application  code  and  Interrupt  Service  Routine  (ISR)  code, 
effectively  providing  the  functionalRy  of  Enable/Disable  Interrupts  in  a  generalized  interface  which  permRs 
implementations  for  both  uni-processor  and  muRi-processor  systems. 
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3.5.6  Mask/Unmask  Interrupts 

This  unfulfilled  requirement  is  classified  as  "C  (may  be  deferred). 

Requirement:  The  OSIF  Shall  provide  the  ability  to  mask  and  unmask  interrupts.  Note  that  this 
requirement  has  particular  relevance  for  Ada  applications,  as  specified  in  paragraph  3.16.18.  Changes  to 
the  recommendations  should  take  that  fact  into  account. 

Description  of  Delta:  Within  the  limits  discussed  under  requirement  3.5.2  (i.e.,  POSIX  does  not 
provide  for  the  collection  and  coordination  of  all  events  and  errors),  POSIX  provides  the  ability  to  mask  and 
unmask  events  through  its  signal  processing  (1003.1).  Therefore,  complete  resolution  of  the  deltas  for 
this  requirement  depend  on  the  resolution  of  requirement  3.5.2. 

While  POSIX  does  currently  provide  the  capability  to  handle  interrupts  in  PI 003.4b,  the  interfaces 
therein  do  not  provide  the  capability  to  mask  and  unmask  intermpts.  Hardware  dependencies  make  it 
inappropriate  to  standardize  such  interfaces. 

Recommendation:  We  recommend  that  the  OSSWG  view  the  masking  and  unmasking  of 
interrupts  as  inappropriate  for  standardization. 


Requirements  Coverage  Summary 
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5.6 
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3.6  FILE  INTERFACES 

In  general,  the  POSIX  standards  support  service  class  6  in  a  substantially  complete  way.  The 
information  that  follows  was  primarily  derived  from  1003.1,  1003.4,  P1003.4a,  and  P1003.4b 
documentation. 

If  you  use  Ada  DirectJO  over  POSIX  files,  then  the  1003.5  Change_WorkingLDirectory  operation 
in  package  POSIX_Process_Environment  shoukf  be  done  at  system  initialization  to  establish  the  default 
working  directory. 

The  requirements  for:  Contiguous  Read  of  a  File  (6.1),  Protect  an  Area  Within  a  File  (6.2),  File 
Management  Suspend/Resume  for  Process  (6.4),  File  Management  Block  Requests  (6.5),  Create  (6.16), 
Open  (6.7),  Point  within  a  file  (6.8),  Read  (6.9),  Write  (6.19),  Write  Contiguous  (6.20),  Close  (6.10),  Delete 
a  file  (6.11),  Create  (6.12),  Specify  Default  (6.13),  Delete  directories  (6.14),  and  Query  or  Modify  File 
attrbutes  (6.17  •  6.18)  are  directly  met  by  a  combination  of  1003.1, 1003.4,  and  PI  003.4b.  Shadow  Files 
(6.15)  is  met  by  the  interfaces  listed  above  in  combination  with  resource  locking  and/or  mutual  exclusion 
interfaces  provided  by  1003.4  and  Pi  003.4a. 
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The  requirement  for:  Fite  Management  Scheduling  (6.3)  is  not  met  or  insufficiently  met  by 
POSIX.  File  Management  Scheduling  requires  a  method  to  specify  a  response  time  for  file  requests. 
POSIX  does  not  Include  this  as  part  of  the  file  interface. 

Note  that  both  Ada  and  POSIX  define  file  operations.  The  two  I/O  systems  are  not  based  on 
identical  file  models.  The  POSIX  I/O  system  has  the  objective  of  making  the  POSIX  I/O  model  available  to 
the  user.  VA/ith  both  sets  of  I/O  operations  available,  it  is  possible  that  a  given  collection  of  application 
programs  will  use  both  sets  of  operations.  For  this  reason,  it  is  desirable  to  permit  the  interchange  of 
external  files  so  that  they  can  be  read  and  updated  by  the  use  of  either  set  of  I/O  operations  after  being 
created  and  written  by  a  different  set  of  I/O  operations.  Thus,  POSIX  extends  the  Ada  file  model  in  several 
useful  ways,  including: 

•  a  hierarchical,  persistent  file  name-space 

-  file/device  control 

-  memory  mapping  (of  files) 

-  standard  error-ou^t  file 

-  appending  to  a  sequential  file 

•  files  with  records  of  mixed  types  and  sizes 

The  POSIX  I/O  system  does  not  have  the  objective  of  incorporating  all  the  functionality  of  the  Ada 
I/O  model.  Instead,  it  interprets  relevant  portions  of  the  Ada  LRM  and  constrains  and  details  some  of  the 
implementation  dependencies  permitted  by  the  Ada  LRM  so  that  Ada  I/O  is  more  rompletely  defined  in  a 
POSIX  environment.  Thus,  the  POSIX  I/O  model  fits  the  Ada  I/O  model  fairly  well. 

Unfortunately,  a  complete  mapping  between  the  POSIX  and  Ada  I/O  operations  is  quite  difficult, 
primarily  because  of  the  lack  of  underlying  standardization  concerning  external  representations  of  data. 
On  a  POSIX  system,  Ada  external  files  are  implemented  as  POSIX  files,  but  the  view  of  a  file  via  the  Ada  I/O 
packages  is  different  from  the  view  via  the  POSIX  interfaces.  There  is  also  a  difference  between  portable 
character  sets,  though  this  is  likely  to  be  reduced  in  Ada  9X.  Furthermore,  the  combination  of  POSIX  and 
Ada  files  does  create  the  possibility  of  some  new  errors.  In  general,  the  effects  of  interleaved  Ada  and 
POSIX  operations  on  the  same  open  file  are  unpredictable.  The  POSIX  Ada  binding  provides  a  way  to 
open  an  Ada  file  object  with  a  specified  POSIX  file  descriptor,  but  states  that  the  effect  is  implementation- 
defined. 


3.6.1  Contiguous  Read  of  a  File 

This  requirement  is  directly  met  by  a  1003.1  Input/Output  Primitives;  1003.4  Asynchronous  or 
List  Directed  I/O  and  Memory  Mapped  Files;  and  PI 003.4b  Advisory  Information. 


3.6.2  Protect  An  Area  Within  A  file 

This  requirement  is  directly  met  by  1003.1  open()  and  File  Control;  and  1003.4  Memory  Mapped 

Files. 


3.6.3  File  Management  Scheduling 

This  unfulfilled  requirement  is  classified  as  "c”  (may  be  deferred). 

Requirement:  The  OSIF  shall  support  a  capability  to  specify  a  response  requirement  for  the 
service  being  requested  for  file  management. 

Requirement  Rationale:  For  hard  deadline  real-time  systems,  the  file  manager  must  schedule 
service  processing  based  on  the  response  requirements  of  the  requests  submitted  by  the  users.  FIFO 
sche^ling  is  unacceptabie  for  reai-time  applications.  The  file  manager  must  also  support  the  notion  of 
preemption. 
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Description  of  Detta:  POSIX  does  not  require  a  method  for  specifying  a  response  time  for 
scheduling  I/O. 

Resplution  Alternatives: 

1.  Enhance  existing  POSIX  interfaces  to  include  this  capability.  The  1003.4  working 
group  is  unable  to  identify  existing  practice  for  such  interfaces,  and  thus  does  not  consider  this 
appropriate  for  standardization  under  the  1003.4  charter. 

2.  Submit  a  new  POSIX  PAR  to  do  this  work.  The  availability  of  people  to  do  this  work  is 
questionable.  People  would  probably  have  to  come  largely  from  OSSWG  as  general  interest  in 
the  POSIX  community  for  this  kind  of  activity  seems  to  be  low. 

3.  Assume  a  standard  outside  POSIX.  No  standards  that  answer  this  kind  of  requirement 
are  apparent  at  this  time. 

4.  Develop  a  new  military  standard.  This  is  a  less  acceptable  alternative  than  2  because  it 
is  external  to  the  OSIP  baseline.  At  the  same  time,  it  suffers  from  the  same  handicaps  as  2,  lack  of 
people  to  do  the  work 

5.  Levy  the  requirements  on  vendors  without  a  standard  imposed.  This  alternative  relies 
on  vendors  to  develop  some  commercial  existing  practice  in  this  area  on  which  to  potentially 
standardize  at  a  later  date. 

Recommendation:  Based  on  alternative  1,  we  recommend  that  the  OSSWG  view  File 
Management  Scheduling  as  inappropriate  for  standardization. 


3.6.4  File  Management  Suspend/Resume  for  Processes 

This  requirement  is  directly  met  by  1003.1  blocking  and  non-blocking  open()  and  write();  1003.4 
Asynchronous  I/O;  and  PI  003.4b  Device  Control. 


3.6.5  File  Management  Block  Requests 

This  requirement  is  directly  met  by  1003.1  read(),  write(),  and  lseek();  1003.4  Memory  Mapped 
Files;  and  PI  003.4b  Advisory  Information. 


3.6.6  Round  Robin  File  Management 

This  requirement  has  been  deleted. 


3.6.7  Open  a  File 

This  requirement  is  directly  met  by  1003.1  open();  1003.4  open();  and  P1003.4b  /kdvisory 
Information. 


3.6.8  Point  Within  a  File 

This  requirement  is  directly  met  by  1003.1  lseek();  and  1003.4  Memory  Mapped  Files. 
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3.6.9  Read  a  File 

This  requirement  is  directly  met  by  1003.1  read():  and  1003.4  Asynchronous  or  List  Directed 
Read  and  Memory  Mapped  Files. 

The  Ada  standard  Direct  JO  package  will  be  provided  as  part  ot  standard  Ada.  This  package 
contains  two  READ  file  operations.  The  input  parameters  for  the  first  read  operation  include  the  FILE 
identifier  and  the  index  to  read  FROM  the  file.  The  second  read  operation  is  an  overloaded  version  of  the 
first  without  the  parameter  identifying  the  index  to  read  FROM.  The  only  output  parameter  for  both  read 
operations  contains  the  ITEM  to  be  read. 


3.6.10  Close  a  File 

This  requirement  is  directly  met  by  1003.1  ciose(). 

The  Ada  standard  Direct  JO  package  will  be  provided  as  part  of  standard  Ada.  This  package 
contains  a  CLOSE  file  operation.  The  only  parameter  is  both  input  and  output  and  is  the  FILE  identifier. 

3.6.11  Delete  a  File 

This  requirement  is  directly  met  by  1003.1  unlir^O;  and  1003.2  "rm.” 

The  Ada  standard  Direct  JO  package  will  be  provided  as  part  of  standard  Ada.  This  package 
contains  a  DELETE  file  operation.  The  only  parameter  is  both  input  and  output  and  is  the  FILE  identifier. 

3.6.12  Create  a  Directory 

This  requirement  is  directly  met  by  1003.1  mkdir();  and  1003.2  "mkdir.” 

3.6.13  Specifying  Default  Directory 

This  requirement  is  directly  met  by  1003.1  chdir();  and  1003.2  "cd." 

3.6.14  Delete  a  Directory 

This  requirement  is  directly  met  by  1003.1  rmdir();  and  1003.2  "rmdir." 


3.6.15  Shadow  Files 

This  requirement  is  "shall  support*  and  is  thus  met  by  the  interfaces  listed  above  in  combination 
with  resource  locking  and/or  mutual  exclusion  interfaces  provided  by  1003.4  and  P1003.4a.  However, 
because  these  interfaces  do  not  necessarily  provide  sufficient  support  to  maintain  shadow  files  at  several 
nodes  of  a  distributed  system,  this  delta  must  be  carefully  re-evaluated  if  this  requirement  is  rTX>dified  to 
explicitly  call  out  distributed  shadow  file  support. 

3.6.16  Create  a  File 

This  requirement  is  directly  met  by  1003.1  open()  and  creat(). 
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The  Ada  standard  Direct_IO  package  will  be  provided  as  part  of  standard  Ada.  This  package 
contains  a  CREATE  file  operation.  The  only  input  output  parameter  is  the  FILE  identifier.  The  input 
parameters  include  the  MODE,  file  NAME,  and  a  FORM  parameter.  The  MODE  parameter  identifies  the 
file  as  read  only,  write  only,  or  both  read  and  write.  The  file  NAME  is  a  string  identtfying  the  name  of  the 
file.  The  FORM  parameter  is  a  string  which  is  user  defined.  The  POSIX_Supplement_To_Ada_IO 
defined  in  1003.5/8.2  will  be  used  to  build  a  POSIX-compliant  FORM  parameter. 


3.6.17  Query  File  Attributes 

This  requirement  is  directly  met  by  1003.1  stat(),  fstat(),  access(),  and  lseek(). 


3.6.18  Modify  File  Attributes 

This  requirement  is  directly  met  by  1003.1  chmod(),  chown(),  utime(),  and  lseek();  1003.4 
ftmncateO;  and  PI 003.4b  Advisory  Information.  Also,  P1 003.2  provides  the  "chmod”  shell  command  to 
meet  this  requirement. 


3.6.19  Write  a  File 

This  requirement  is  directly  met  by  1003.1  write();  and  1003.4  Asynchronous  or  List  Directed 
Write  and  Memory  Mapped  Files. 

The  Ada  standard  Direct.lO  package  will  be  provided  as  pari  of  standard  Ada.  This  package 
contains  two  WRITE  file  operations.  The  input  parameters  for  the  first  write  operation  include  the  FILE 
identifier  and  the  index  to  write  TO  the  file.  The  second  write  operation  is  an  overloaded  version  of  the 
first  without  the  parameter  identifying  the  index  to  write  TO.  The  only  output  parameter  for  both  write 
operations  contains  the  ITEM  to  be  written. 


3.6.20  Write  Contiguous  File 

This  requirement  is  directly  met  by  1003.1  write();  1003.4  Asynchronous  or  List  Directed  Write 
and  Memory  Mapped  Files;  and  PI  003.4b  Advisory  Information. 
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3.7  GENERALIZED  I/O  INTERFACES 

In  general,  the  POSIX  standards  support  service  class  7,  generalized  I/O,  in  a  substantially 
complete  way.  This  is  assuming  the  definition  of  a  lile”  found  in  1003.1  section  2.3,  includes  any  and  all 
devices.  This  means  that  any  device  can  be  represented  by  a  file. 


3.7.1  Device  Driver  Availability 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 

This  requirement  for  device  driver  availability  (7.1)  is  not  met  by  POSIX  and  is  considered  by 
POSIX  to  be  im^ementation  dependent. 

Requirement:  The  OSIP  shall  provide  the  interfaces  necessary  to  support  the  addition  of  device 

drivers. 

Description  of  Delta:  PI 003.4b  Interrupt  Control  allows  application  servicing  of  device  interrupts. 
1003.4  mmap()  allows  devices  to  be  memory  mapped,  but  only  for  devices  currently  known  to  the  system 
as  special  files.  Not  all  operating  system  services  typically  required  by  a  device  driver  are  shown  at  the 
POSIX  interface  (e.g.  mapping  a  user  buffer  to  a  DMA  address). 

RBSQlutton  Alternatives: 

1.  Enhance  existing  POSIX  interfaces  to  include  this  capability.  This  requirement  could 
be  inserted  into  P1 003.7  system  administration.  In  the  PI  003.7  document,  place  holders  exist 
for  interfaces  which  would  be  the  same  type  of  interfaces  needed  for  device  drivers. 
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2.  Assume  a  standard  outside  of  POSIX.  The  IEEE  Pi  256  OBIOS  group  is  presently 
woitdng  on  standardizing  device  driver  interfaces.  The  apfXicability  of  this  standard  to  the  OSSWG 
operating  system  standard  needs  to  be  investigated. 

3.  OSSWG  defined  based  on  existing  practice. 

Recommendation:  Alternative  1  should  be  pursued. 


3.7.2  Open  Device 

This  requirement  is  met  directly  by  1003.1  General  File  Creation,  and  1003.5  Creating  and 
Removing  Files. 


3.7.3  Close  Device 

This  requirement  is  met  directly  by  1003.1  File  Descriptor  Deassignment,  and  1003.5  Close. 


3.7.4  Transmit  Data 

This  requirement  is  met  directly  by  1003.1  Write,  1003.4  Asynchronous  Write,  1003.4  List 
Directed  I/O.  and  1003.4  Memory  Mapping  of  special  files  (devices).  The  Ada  interfaces  appropriate  for 
transmitting  data  include  1003.5  Write  and  Generic  Write.  The  Ada  generic  write  allows  the  user  to  identify 
a  data  type  appropriate  for  the  data  which  is  sent. 


3.7.5  Receive  Data 

This  requirement  is  met  directly  by  1003.1  Read,  1003.4  Asynchronous  Read,  1003.4  List 
Directed  I/O,  and  1003.4  Memory  Mapping  of  special  files  (devices).  The  Ada  interfaces  appropriate  for 
receive  data  include  Read  and  Generic  Read.  The  Ada  generic  read  allows  the  user  to  identify  a  data 
type  appropriate  for  the  data  which  is  received. 


3.7.6  Device  Event  Notification 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 

Device  Event  Notification  is  a  compound  requirement  comprising  requirements  5.1  (Event  and 
Error  Receipt),  5.2  (Event  and  Error  Distribution),  5.3  (Event  and  Error  Management),  5.4  (Event 
Logging).  5.5  (Enable/Disable  Interrupts),  and  5.6  (Mask/Unmask  Interrupts)  applied  specifically  to  events, 
errors,  and  interrupts  originating  at  a  peripheral  device.  It  remains  unfulfilled  to  the  extent  that  any  of  its 
dependent  requirements  remains  unfulfilled  for  devices.  Refer  to  section  3.5,  Event  and  Error  Interfaces 
for  specific  information  on  those  requirements. 


3.7.7  Control  Device 

This  requirement  is  directly  met  by  1003.1  Control  Operations  on  RIes,  1003.1  General  Terminal 
Interface,  1003.5  File  Control,  and  1003.4b  Device  Control. 
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3.7.8  I/O  Directory  Services 

The  requirement  for  I/O  directory  services  is  met  directly  by  1003.1  Files  and  Directories, 
Pi 003. la  File  Hierarchy  Streams,  and  1003.5  Packages  POSIX_Files  and  POSIX_File_Status. 

3.7.9  Device  Management  Suspend/Resume  for  Processes 

This  requirement  is  fully  met  by  1003.1  Open  a  File,  1003.1  Read  from  a  File  (device),  1003.1 
Write  to  a  File  (device),  1003.4  Asynchronous  Input  and  Output,  P1003.4b  Device  Control,  ar^  1003.5 
Read.  Wrtte,  Gcmric  Read.  Generic  Write. 

3.7.10  Mount/Dismount  Device 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 

This  requirement  is  not  met  by  POSIX  arKf  is  considered  by  POSIX  to  be  implementation 
dependent. 

Requirement:  The  OSIF  shall  support  the  capability  to  rTX>unt  and  dismount  a  logical  or  physical 

device. 


Description  of  Delta:  Not  presently  shown  at  POSIX  Interface 

Resolution  AltamatiYas: 

1 .  Enhance  existing  POSIX  interfaces  to  include  this  capability.  This  requirement  could 
be  inserted  into  PI 003.7  system  administration.  In  the  PI  003.7  document,  place  holders  exist 
for  interfaces  which  would  be  the  same  type  of  interfaces  needed  for  mounting  and  dismounting  a 
device.  This  was  deferred  to  Pi  003.7.5  for  which  no  draft  has  yet  been  generated. 

2.  OSSWG  defined  based  on  existing  practice. 

Recommendation:  Insert  into  a  PI 003.7  system  administration  document. 


3.7.11  Initialize/Purge  Device 

This  requirement  is  directly  met  by  1003.1  General  Terminal  Interface,  and  P1003.4b  Device 

Control. 
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Requirements  Coverage  Summary 
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3.8  NETWORK  AND  COMMUNICATIONS  INTERFACES 

In  general,  the  POSIX  Standards  partially  support  Service  Class  8,  Network  and  Communication 
Interfaces.  Most  of  the  input  to  the  evaluation  of  this  service  class  is  derived  from  the  1003.12  protocol 
independent  interfaces  working  group,  the  1238  ACSE  and  Presentation  API  working  group,  the  1238.1 
FTAM  API  working  group,  the  1224.2  directory  services  API  working  group,  and  the  Realtime  Distributed 
Systems  Communication  API  (1003.21)  project.  The  Realtime  Distributed  Systems  Communication  study 
group  first  met  in  July,  1992,  as  a  1003.12  splinter  group;  it  submitted  a  PAR  as  a  separate  POSIX  working 
group  in  fall.  1992.  The  PAR  was  subsequently  approved  as  1003.21 . 

The  1003.12  working  group  is  developing  two  levels  of  networking  interfaces.  One  is  the  Simple 
Network  Interface  (SNI).  The  other  is  the  Detailed  Network  Interface  (DNI).  DNI  will  have  two  C  bindings, 
Berkeley  sockets  and  X/Open's  XTI  (the  standardized  version  of  AT&Ts  Transport  Layer  Interface  (TLI)). 
The  two  C  bindings  position  is  a  compromise  resulting  from  the  controversy  over  whether  to  choose 
sockets.  XTI.  or  a  third  interface  made  up  of  elements  from  both  sockets  and  XTI  as  the  DNI. 

1003.21  plans  to  develop  protocol  independent  interfaces  that  are  complementary  to  realtime 
systems.  They  plan  to  use  the  work  done  by  SEI  as  an  Ada  binding  to  the  SAFENET  Lightweight  protocol 
suite  as  a  base  document  for  their  work. 

In  light  of  the  nature  of  the  1003.21  work  as  well  as  the  P1003.12, 1238, 1238.1  and  1224.2  work 
and  their  close  association  with  the  Network  and  Communications  Interfaces  service  class,  the  OSSWG 
needs  to  monitor  progress  in  these  groups  closely. 

In  a  system  using  components  based  on  NGCR  standards,  there  will  frequently  be  a  hierarchy  of 
networked  communication,  data  storage,  and  processing  functions.  At  the  base  of  this  hierarchy  may  be  a 
number  of  processing  or  storage  units  on  a  single  board  connected  by  an  onboard  bus.  At  the  next  level 
will  be  FUTUREBUS-i-  or  non-NGCR  backplane  busses  (e.g.,  VME).  At  the  next  level  there  may  be 
SAFENET,  MIL-STD-1553B  data  busses,  or  non-NGCR-defined  LANs.  At  the  highest  level,  but  outside 
the  scope  of  this  set  of  requirements,  there  may  be  communications  among  systems  on  different  Navy 
platforms.  In  some  application  domains  and  for  some  application  functions,  the  OSIF  must  provide  explidt 
access  to  networked  communication,  data  storage,  and  processing  functions  for  both  NGCR-defined 
communication  corrqaonents  and  similar  non-NGCR-defined  components.  This  is  in  addition  to  the  use  of 
these  capabilities  implied  in  many  other  requirements.  Two  processes  make  up  a  communications 
transaction  regardless  of  their  location.  This  includes  either  two  processes  across  a  communications  link 
or  two  processes  residing  on  the  same  processor. 
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OSSWG  has  exprsssed  some  concern  that  requirements  8.3  (Acknowledged  Connection- 
Orienled  Service)  and  8.4  (Unacknowledged  Connection^riented  ^rvice)  actually  dictate  two  protocol- 
specific  implementations  of  Connection-Oriented  Service  intended  to  exploit  a  trade-off  between  highly 
ratable  delivety  and  high  performance.  The  same  can  be  said  of  requirements  8.5  (Acknowledged 
Datagram  Service)  arnf  8.6  (Datagram  Service),  it  has  been  suggested  th^  these  requirements  be  re¬ 
worded  to  state  true  requirements:  that  is,  Conrtection-Oriented  Service  or  Datagram  Senrice  whh 
specified  levels  reliabittty  and  performance.  This  is  more  in  keeping  wtth  the  P1003.12  concept  of 
Quality  of  Senrice  pwameters.  and  isolates  the  requirements  from  dependency  on  current  network 
protocol  impiementations.  However,  since  the  Acknowtedged/Unacknowledged  pai^igm  is  so  pervasive 
throughout  current  networking  technology,  OSSWG  is  reluctant  to  change  these  requirements  without 
further  study.  OSSWG  recommerKfs  that  this  issue  be  addressed  as  part  of  an  overall  review  of  all  the 
OCD  requirements. 


3.8.1  Interface  to  NAVY  Standard  Network 

This  urrfulfilled  requirement  is  classified  as  ‘a*  (essential). 

This  requirement  is  partially  covered  by  the  work  of  1238  and  1238.1  which  provide  interfaces  to 
the  SAFENET  OSI  suite;  1224.2  which  provides  an  interface  to  directory  services;  and  Pi  003.1 2  and 
1003.21  which  provide  interfaces  to  the  SAFENET  lightweight  suite.  1003.21  is  attempting  to  make  their 
interface  also  applicable  to  backplane  buses  such  as  Futurebus-t-.  Only  1003.21  plans  to  provide  an  Ada 
binding  to  its  interface.  Additionaliy,  the  POSIX  12XX  series  of  standards  does  not  currently  include 
interfaces  for  ROSE  or  network  management  which  are  needed  to  support  the  SAFENET  OSI  suite. 

Requirement:  The  operating  system  shall  provide  explicit  interfaces  to  and  control  of  NGCR 
starKfard  communications  implementations.  These  knpiementations  shall  include  but  not  be  limited  to 
implementations  of  Futurebus+  and  SAFENET. 

PescrlPtlQn  of  Delta:  POSIX/12XX  provide  no  interfaces  for  ROSE  or  network  management,  both 
of  which  are  needed  to  provide  a  complete  interface  to  SAFENET. 

Recommendation:  Pursue/support  PARs  for  interfaces  to  ROSE  and  network  management. 


3.8.2  Interfaces  to  Other  Network  and  Communication  Entities 

This  requirement  is  met  in  various  ways.  Explicit  interfaces  exist  in  PI 003. 12  for  interfacing  to 
networks  (Ethernet  and  FDDI),  usually  using  additional  protocols  (TCP/IP  auid  ISO),  interfaces  also  exist  to 
access  devices  via  1003.1  Infxjt  and  Output  Primitives.  Although  device  drivers  are  needed  to  access 
devices  such  as  MIL-STO-1S53B,  these  interfaces  can  be  used  In  a  portable  manner.  Finally,  it  is 
generally  accepted  that  access  to  backplane  busses  (VME,  MULTIBUS,  and  Pi-Bus)  is  not  explicitly  given 
to  applic^ns  and  the  details  of  backplane  communication  are  regarded  as  an  implementation  issue. 


3.8.3  Acknowledged  Connection-Oriented  Service 

There  is  no  delta  for  this  requirement.  The  work  of  the  1351, 1003.12,  and  1003.21  groups  will 
satisfy  this  requirement.  Only  the  1003.21  group  plans  to  provide  an  Ada  binding. 

There  is  some  concern  within  the  OSSWG  that  1003.21  will  "overfulfiir  this  requirement;  that  is,  if 
1003.21  develops  alternative  interfaces  to  Acknowledged  Connection-Oriented  Service  (as  opposed  to 
simply  Ada  bindings  for  those  already  developed  by  the  1238  and  1003.12  groups),  it  is  not  clear  that 
having  two  sets  of  interfaces  will  be  advantageous. 
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3.8.8  Broadeast/Multicast  Service 

This  unfUMHed  requirement  is  ciassiTied  as  "a"  (essentiaO- 

There  wiH  be  m  delta  for  this  requirement  H  the  1003.21  work  proceeds  as  planned.  Broadcast 
and  muMcast  requirements  appear  in  the  1003.21  requirements  document  and  broadcast  and  multicast 
services  appear  in  the  1003.21  Ada  binding  base  document. 

Requirement:  The  OSIF  shall  provide  for  the  selection  of  broadcast/multicast  communication 
senrices. 


Description  of  Delta:  No  delta/dependent  on  1003.21  group  work. 

Recommendation:  Monitor/influence  1003.21  group  work.  OSSWG  is  concerned  that  the 

1003.21  group  is  not  making  adequate  progress  in  defining  this  interface  and  may  not  provide  a  C- 
Language  binding  to  this  interface;  therefore  the  1003.12  group  should  be  considered  as  a  backup. 

3.8.9  K-Acknowledged  Multicast  Service 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 

There  will  be  no  delta  for  this  requirement  if  the  1003.21  work  proceeds  as  planned.  The 

1003.21  requirements  document  discusses  a  k-acknowiedged  multicast  service  and  the  1003.21  Ada 
binding  base  document  specifies  an  active-group-integrity  quality-of-service  parameter  on  multicast 
services  which  also  implies  k-acknowier^ment. 

Requirement:  The  OSIF  shall  provide  for  the  selection  of  multicast  communication  services  that 
ensure  reliable  delivery  to  at  least  k  of  n  multicast  group  members. 

Description  of  Delta:  No  delta/dependent  on  1003.21  group  work. 

Recommendation:  Monitor/influence  1003.21  group  work.  OSSWG  is  concerned  that  the 

1003.21  group  is  not  making  adequate  progress  in  defining  this  intedace  and  may  not  provide  a  C- 
Language  binding  to  this  intedace;  therefore  the  1003.12  group  should  be  considered  as  a  backup. 


3.8.10  Atomic  Multicast  Service 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 

There  will  be  no  delta  for  this  requirement  if  the  1003.21  work  proceeds  as  planned.  A  multicast 
transaction  requirement  appears  in  the  1003.21  requirements  document  and  a  multicast  transaction 
service  appears  in  the  1003.21  Ada  binding  base  document. 

Requirement:  The  OSIF  shall  provide  for  the  selection  of  reliable,  atomic  multicast 
communications  services. 

Description  of  Delta:  No  delta/dependent  on  1003.21  group  work. 

Recommendation:  Monitor/influence  1003.21  group  work.  OSSWG  is  concerned  that  the 

1003.21  group  is  not  making  adequate  progress  in  defining  this  intedace  and  may  not  provide  a  C- 
Language  binding  to  this  intedace;  therefore  the  1003.12  group  should  be  considered  as  a  backup. 
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3.9  PROCESS  MANAGEMENT  INTERFACES 

In  general,  the  POSIX  Standards  support  Service  Class  9,  Process  Management,  in  a  substantially 
complete  way  for  both  the  Rhread  Mode'  ar  1  the  POSIX  process  model. 

OSSWG  r^ires  a  single  un't  of  ooncunency,  namely  the  'process.”  1003.1  and  1003.4  support 
this  requirement  via  the  POSIX  process  model,  while  PI 003.4a  adds  a  second  level  of  concurrency 
(within  a  POSIX  process)  calleo  POSIX  threads.  Depending  on  the  application,  an  OSSWG  'process'  may 
be  either  a  POSIX  process  or  a  POSIX  thread.  Furthermore,  some  applications  (particularly  in  Ada)  may 
require  simultaneous  use  of  both  concurrency  models.  Therefore,  this  analysis  separately  considers  each 
requirement  as  it  is  met  by  POSIX  processes  and  by  POSIX  threads  (Pthreads). 

The  ability  to  create  processes  is  an  essential  part  of  the  POSIX  interface  and  an  Ada  binding  to 
POSIX  without  processes  would  be  incomplete.  Nevertheless,  it  is  possible  that  the  POSIX  process 
model  is  at  odds  with  the  Ada  multitasking  model,  particularly  since  a  standard  mapping  between  these 
two  models  does  not  exist.  Therefore,  Ada  programmers  should  be  aware  of  potential  conflicts  that  can 
occur  when  creating  POSIX  processes. 

In  an  attempt  to  reconcile  the  Ada  and  POSIX  models  of  concurrency  there  seems  to  be  three 
potential  mappings;  1)  each  Ada  task  is  a  POSIX  process,  2)  each  Ada  program  is  a  POSIX  process,  or  3) 
there  is  not  a  simple  relationship  between  POSiX  processes  and  Ada  tasks.  The  choice  that  causes  the 
least  (»nflict  between  Ada  and  POSIX  is  to  require  that  the  POSIX  Ada  standard  interface  to  POSIX 
impose  a  virtual  one-to-one  correspondence  between  processes  and  program  executions.  That  is,  an 
Ada  program  execution  should  act,  feel,  and  look  as  if  it  is  running  as  a  single  POSIX  process.  This 
equivalence  between  a  POSIX  process  and  an  Ada  program  means  that  one  cannot  differentiate  between 
the  two  POSIX  calls.  This  choice  has  the  virtue  of  raising  the  fewest  problems  and  resolving  many  issues 
cleanly.  The  Pf  003.5  standard  accommodates  this  idea  by  isoiating  those  features  of  POSIX  that  deal 
with  process  creation  within  the  packages  POSlX_Process_Primitives,  POSIX- 
Unsafe_Process_Primitives,  and  POSIX_ProcessJdentification. 


3.9.1  Create  Process 

The  requirement  for  Create  Process  (9.1)  is  directly  met  for  Pthreads  by  PI  003.4a  plus  the 
interprocess  communication  facilities  of  1003.4.  The  Create  Process  (9.1)  requirement  is  met  for 
processes  by  the  fork  and  exec  interfaces  of  1003.1,  the  spawn  interface  of  PI  003.4b,  the  scheduling 
interface  of  1003.4,  plus  the  communication  and  synchronization  interfaces  of  1003.4.  lire  use  of  these 
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interfaces  br  oombtaiation  to  meet  the  requiremers  is  adequate  since  the  requirement  is  stated  as  "shay 
support."  P1003.1a  provides  a  system()  interface  to  1003.2  shell  commands  to  meet  this  requirement. 


3.9.2  Terminate  Process 

This  unfulfilled  requirement  is  classified  as  "a*  (essential). 

The  requirement  for  Terminate  Process  (9.2)  is  almost  met  for  Rhreads  by  PI 003.4a  plus  the 
interprocess  communication  facilities  of  1003.4.  The  requirement  for  Terminate  Process  (9.2)  is  directly 
met  for  POSIX  processes  by  1003.1  process  interfaces  plus  1003.4  process  attributes  and  irtterprocess 
communication  facilities.  Also,  for  processes  only.  1003.2  provides  the  "kiir  shell  command  to  meet  this 
requirement. 

Requirement:  The  OSIF  shall  support  the  ability  to  terminate  a  process  and  recover  all  resources 
associated  with  that  process. 

Description  of  Delta:  Pthread_kill()  cannot  unconditionally  terminate  another  thread  (it  will 
terminate  the  entire  process  instead),  and  pthread.cancelQ  also  cannot  unconditionally  terminate  another 
thread  (that  thread  may  have  disabled  cancellation).  Therefore,  there  is  no  interlace  to  unconditionally 
terminate  another  thread. 

Recommendation:  OSSWG  should  influence  the  1003.4  working  group  to  provide  an  interface 
by  which  one  thread  may  unconditionally  terminate  another  thread.  This  appears  to  be  a  technical 
correction  (or  addition)  to  PI 003.4a,  and  can  possbiy  be  achieved  through  the  P1003.4d  project. 


3.9.3  Start  Process 

The  requirement  (or  Start  Process  (9.3)  was  purposely  rejected  as  a  separate  interface  by 
P1003.4a  in  favor  of  use  of  the  Pthread  synchronization  primitives  to  achieve  the  same  effect  whenever 
process  creation  and  startup  must  be  separately  managed.  This  alternative  capability  is  adequate  to  meet 
this  "shall  support"  requirement.  The  requirement  for  Start  Process  (9.3)  is  also  not  separately  addressed 
for  POSIX  processes.  The  requirement  is  met  by  the  1003.1  fork(),  execl(),  and  execve()  interfaces  and 
by  the  P1003.1a  system()  interface  to  1003.2  shell  commands.  It  is  indirectly  supported  via  the  1003.1 
and  1003.4  process  synchronization  interfaces,  much  as  in  the  case  of  Pthreads.  Since  this  is  a  "shall 
support"  requirement,  it  is  met  by  a  combination  of  POSIX  process  synchronization  primitives. 


3.9.4  Stop  Process 

The  requirement  for  Stop  Process  (9.4)  is  not  addressed  by  POSIX  for  either  Rhreads  or  POSIX 
processes.  The  whole  concept  of  stopping  a  process  for  subsequent  restart  (from  a  point  other  than 
where  it  was  stopped)  is  considered  by  POSIX  as  an  application  dependent  variant  of  a  thread  or  process 
becoming  blocked  and  subsequently  unblocked.  Since  POSIX  does  indirectly  sujsport  Suspend  Process 
(q.v.),  arid  standard  languages  support  both  local  and  non-local  jumps,  this  "shall  support"  requirement  is 
considered  met  by  POSIX. 


3.9.5  Suspend  Process 

The  requirement  for  Suspend  Process  (9.5)  is  met  for  both  Rhreads  and  POSIX  processes  by 
combinations  of  interfaces  in  1003.1,  1003.4,  and  P1003.4a.  Although  no  Rhread  or  POSIX  process 
interface  explicitly  provides  each  of  these  capabilities,  the  requirement  is  met  by  combining  interfaces. 
The  POSIX  community  regards  asynchronously  affecting  the  state  of  another  process  or  thread  as  a 
dangerous  capability,  and  suggests  that  this  be  accomplished  by  asynchronously  or  synchronously 
requesting  the  other  thread  change  its  own  state. 
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3.9.6  Resume  Process 

The  requirement  for  Resume  Process  (9.6)  is  met  for  tx>th  Pthreads  arKt  POSIX 
processes  by  combinations  of  interfaces  in  1003.1,  1003.4,  and  Pi  003.4a.  AKhough  no  Rhread  or 
POSIX  process  interface  explicitly  provides  each  of  these  capabilities,  the  requirement  is  met  by 
combining  interfaces.  The  POSIX  community  regards  asynchronously  affecting  the  state  of  another 
process  or  thread  as  a  dangerous  capability,  and  suggests  that  this  be  accomplished  by  asynchronously 
or  synchronously  requesting  the  other  thread  change  its  own  state. 


3.9.7  Delay  process 

The  requirement  for  Delay  Process  (9.7)  is  met  for  both  Rhreads  and  POSIX  processes 
oombirtations  of  interfaces  in  1003.1,  1003.4,  and  Pi003.4a.  Although  no  Rhread  or  POSIX  process 
interface  explicitly  provides  each  of  these  capabilities,  the  requirement  is  met  by  combining  interfaces. 
The  POSIX  community  regards  asynchronously  affecting  the  state  of  another  process  or  thread  as  a 
dangerous  capabilHy,  and  suggests  that  this  be  accomplished  by  asynchronously  or  synchronously 
requesting  the  other  thread  change  its  own  state.  Also,  ‘delay  until"  semantics,  although  not  directly 
supported  for  POSIX  processes  or  Rhreads,  can  be  achieved  through  a  combination  of  the  1003.4 
clocks  and  timers  interfaces  and  1003.1, 1003.4  and  PI  003.4a  signal  interfaces.  1003.2  provides  the 
"sleep*  shell  command  to  meet  this  requirement. 


3.9.8  Interprocess  Communication 

The  requirement  for  Interprocess  Communication  (9.8)  is  directly  met  for  Rhreads  by  PI 003.4a 
plus  the  interprocess  communication  facilities  of  1003.4.  The  requirement  for  Interprocess 
Communication  (9.8)  is  directly  met  for  POSIX  processes  by  1003.1  process  interfaces.  PI 003.4 
Synchronization  plus  1003.4  process  attributes  and  interprocess  communication  facilities.  P1 003.1 2 
explicitly  provides  interprocess  communication  interfaces  for  a  distributed/networked  environment. 


3.9.9  Examine  Process  Attributes 

The  requirement  for  Examine  Process  Attributes  (9.9)  is  directly  met  for  Rhreads  by  PI  003.4a  , 
Execution  Time  Monitoring  of  Pi  003.4b.  plus  the  interprocess  communication  facilities  of  1003.4.  The 
requirement  Examirre  Process  Attributes  (9.9)  is  directly  met  for  POSIX  processes  by  1003.1  process 
interfaces.  Execution  Time  Monitoring  of  PI  003.4b,  plus  1003.4  process  attributes  and  interprocess 
communication  facilities.  1003.2  provides  the  "ps*  shell  command  to  meet  this  requirement. 


3.9.10  Modify  Process  Attributes 

The  requirement  for  Modify  Process  Attributes  (9.10)  is  directly  met  for  Rhreads  by  PI  003.4a  , 
Execution  Scheduling  of  PI  003.4b  plus  the  interprocess  communication  facilities  of  1003.4.  The 
requirement  for  Modify  Process  Attributes(9.10)  is  directly  met  for  POSIX  processes  by  1003.1  process 
interfaces  plus  1003.4  process  attrflbutes  and  interprocess  communication  facilities. 


3.9.11  Examine  Process  Status 

This  unfulfilled  requirement  is  classified  as  "a”  (essential). 
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The  requirement  for  Examine  Process  Status  (9.1 1)  is  not  adequately  covered  either  for  Pthreads 
or  POSIX  processes.  Interfaces  to  enable  one  Rhread  or  POSIX  process  to  obtain  the  current  status  of 
another  must  be  added. 


EMmlna  PQSIX  Procaw  Staiua 

Requirement:  The  OSIP  shall  provide  the  ability  for  processes  to  examine  the  current  status  of  a 
particular  process.  Note  that  status  here  is  not  intended  to  include  cumulative  execution  time;  the 
capability  to  obtain  cumulative  execution  time  is  covered  as  requirement  3  in  service  class  13 
(synchronization  and  scheduling). 

Descrtotion  of  Delta:  The  wait()  and  waitpid()  functions  provide  limited  status  (terminated,  stopped, 
and  why  (e.g.,  caused  by  which  signal))  on  limited  processes  (child  processes).  Richer  status  information 
is  required.  The  ability  to  examine  status  of  general  processes  (i.e.,  non-children)  is  required.  1003.2 
provides  the  "ps”  commarKi,  but  no  API  (system  call  version)  is  provided. 

Resolution  Alternatives: 

1.  Enhance  existing  1003.1  wait()  and  waitpid()  interfaces  to  include  this  capability. 
Extensions  of  wait()  and  waitpid()  to  provide  richer  status  information  and  to  allow  status  queryirrg 
to  general  processes  are  discussed  in  1003.1  but  are  not  included  in  the  standard.  It  is  unlikely 
that  a  consensus  to  include  the  extensions  could  be  achieved. 

2.  Incorporate  an  API  to  1003.2  ‘ps*  command  functionality  into  a  POSIX  standard.  The 
functionality  should  be  incorporated  as  a  system  call  and  also  as  a  command  ("ps”  is  available  only 
as  a  command  in  1003.2). 

Recommendation:  The  PI  003.7  drafts  should  be  reviewed  to  determine  whether  a  system  call 
version  of  'ps*  is  on  the  agenda.  The  1 003.7  group  should  be  approached  with  a  proposal  to  include  the 
capability  for  examining  process  status  in  one  of  their  drafts  if  this  is  not  already  on  the  agenda. 

Examine  POSIX  Thread  Status 

Requirement:  The  OSIF  shall  provide  the  ability  for  threads  to  examine  the  current  status  of  a 
particular  thread.  Note  that  status  here  is  not  intended  to  include  cumulative  execution  time;  the  capability 
to  obtain  cumulative  execution  time  is  covered  as  requirement  3  in  service  class  13  (synchronization  and 
scheduling).  Note  also  that  this  requirement  has  particular  relevance  for  Ada  applications,  as  specified  in 
paragraph  3.16.10.  Changes  to  the  recommendations  should  take  that  fact  into  account. 

Description  of  Delta:  The  pthreadjoin  function  provides  limited  status  information:  whether  a 
thread  has  terminated.  Richer  status  information  is  required. 

Resolution  Alternatives: 

1.  Investigate  extending  1003.2  ’ps"  command  functionality  to  threads  and  incorporating  a 
system  call  version  into  a  POSIX  standard.  Although  threads  are  addressed  in  the  1003.4  working  group, 
that  group  does  not  consider  such  an  interface  appropriate  to  standardize  at  this  time  due  to  tack  of 
existing  practice  and  its  tack  of  retevance  to  the  reaKime  charter.  The  1003.7  group  seems  to  be  the  tikely 
place  to  address  this  in  conjunction  with  the  API  for  process  status  discussed  above. 

Recommendation:  Alternative  1  should  be  pursued  in  the  1003.7  working  group  (for  a  thread 
status  API).  1003.2  should  be  requested  to  add  a  thread  status  command  (possibly  based  on  this  API  at  a 
later  date),  but  this  is  less  cnjcial  to  fulfilling  the  OSSWG  requirement. 
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3.9.12  Process  (Thread)  Identification 

The  requirement  for  Process  Identification  (9.12)  is  directly  met  for  Pthreads  by  PI  003.4a  plus 
the  interprocess  communication  facilities  of  1003.4  and  for  POSIX  processes  by  1003.1  process 
interfaces,  1003.4  process  attributes  and  interprocess  communication  facilities,  and  Process 
Management  interfaces  of  Pi  003.4b.  1003.2  provides  the  "ps*  shell  command  to  meet  this  requirement. 


3.9.13  Save/Restart  Process 

This  unfulfilled  requirement  is  classified  as  'a*  (essential). 

The  requirement  for  Save/Restart  Process  (9.13)  is  directly  met  for  POSIX  processes  by  the 
PI 003. la  Process  Checkpoint  and  Restart  capability.  This  requirement  is  not  met  for  Rhreads,  however, 
since  PI  003.4a  defines  no  equivalent  per-thread  capability.  This  is  understandable  since  this  PI  003.4a 
capability  is  relatively  new. 

Requirement:  Tli£  OSIF  shall  support  the  ability  for  processes  to  be  restarted  from  a  saved  state. 
Note  that  this  requirement  has  particular  relevance  for  Ada  applications,  as  specified  in  paragraph  3.16.6. 
Changes  tc  tt.e  recommendatif>ns  shciiid  take  that  fact  into  account. 

Description  of  Delta:  At  thi tt  .se  interfaces  are  not  provided  for  Rhreads. 

Resolution  Alternatives: 

1.  Investigate  checkpointing/restarting  of  threads,  possibly  in  the  context  of  a  broader 

OSSWG  fault  tolerance  proposal.  Consider  1003.7  as  fooims  for  making  proposals. 

2.  Levy  the  requirements  and  the  OSIF  general  requirements  on  vendors  but  do  not 

provide  a  standard  as  such.  This  alternative  relies  on  vendors  to  develop  some  commercial 

existing  practice  in  this  area  on  which  to  potentially  standardize  at  a  later  date. 

Recommendation:  Alternative  1  is  recommended,  while  it  is  recognized  that  program  managers 
can  always  resort  to  alternative  2.  Checkpointing  a  thread  that  is  sharing  memory  with  other  threads  seems 
to  be  difficult  and  demands  further  study. 


3.9.14  Program  Management  Function 

The  requirement  for  Program  Management  (9.14)  is  directly  met  for  Rhreads  by  P1003.4a  plus 
the  interprocess  communication  facilities  of  1003.4.  The  requirement  for  Program  Management  (9.14)  is 
directly  met  for  POSIX  processes  by  1003.1  process  interfaces  plus  1003.4  process  attributes  and 
interprocess  communication  facilities. 
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Requirements  Coverage  Summary 


3.10  PROJECT  SUPPORT  ENVIRONMENT  INTERFACES 

Two  "profile"  related  architectures  are  possible  for  the  implementation  of  the  OSSWG 
requirements  for  debug  support  (see  OCD  Appendix,  20.10.1)  and  execution  history  (OCD  Appendix. 
20.10.2). 

In  architecture  A,  the  process  being  debugged  interfaces  to  the  debugger,  which  in  turn 
interfaces  to  the  operating  system.  Conceptually,  this  is  the  equivalent  to  the  debugged  process 
executing  in  an  application  debugger  "shell"  that  interfaces  to  the  supplied  operating  system.  (Note:  This 
architecture  appears  to  be  the  one  assumed  by  earlier  versions  of  the  OSSWG  Delta  Document.) 
Alternatively,  it  can  be  thought  of  as  the  capability  to  create  an  instnjmented,  self-monitoring  copy  of  the 
target  process.  This  architecture  has  the  following  characteristics; 

1.  It  is  most  naturally  applied  to  general-purpose  RAM-based  development  systems.  These 
systems  would  support  compiling,  linking,  etc. 

2.  There  is  an  essential  link  between  the  debugger  and  other  process  development  tools  (i.e., 
the  compilers,  linkers,  etc.).  The  debug  capability  accesses  the  process  at  the  source  level. 

3.  The  debugger  is  assumed  to  reside  upon  the  application  platform. 

4.  The  debug  functionality  is  supplied  at  the  application  level  and  not  the  operating  system  level. 
Execution  history  can  also  naturally  be  maintained  at  this  application  level  without  additional  OS 
functionality. 

5.  There  is  currently  (for  a  given  language)  a  body  of  practice  in  place  that  supports  the 
Requirements  Document  with  an  indirect  "virtual"  debug  capability  (if  not  the  direct  "physical"  capability, 
i.e.,  the  direct  alteration  of  the  registers  of  an  executing  process). 

Given  the  above  characteristics,  there  does  not  appear  to  be  any  delta  at  the  "kemer  POSIX  level. 
Because  of  the  strong  relationship  between  the  debugger  and  the  compiler,  there  might  be  some 
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language  (Ada,  C,  etc.)  binding  considerations.  This  would  probably  be  a  direct  binding  between  the 
tankage  and  the  debugger  (i.e.,  tool  to  tool)  not  involving  the  OS. 

In  architecture  B,  the  debugger  interfaces  to  the  operating  system,  which  in  turn  interfaces  to  the 
process  being  debugged.  (Note:  This  is  the  architecture  that  appears  to  be  implied  by  figure  f  0.2-2  of  the 
OCD.)  Conceptually,  this  can  be  viewed  as  supplying  external  access  to  a  "target”  system  via  operating 
system  senrices.  This  architecture  has  the  following  characteristics: 

1.  It  is  most  naturally  applied  to  special-purpose  PROM/EPROM-based  systems  (e.g.,  flight 
control  computers). 

2.  There  is  not  necessarily  a  link  between  the  debugger  and  the  compiler,  linker,  etc.,  of  the  target 
process.  The  debug  capability  accesses  the  system  at  the  code  level. 

3.  There  is,  in  general,  a  physical/logical  separation  between  the  application  platform  and  the 
POSIX  Standard  Environment  (PSE)  host  platform.  A  communication  protocol  may  be  necessary  as  part 
of  the  debugger/OS  interface. 

4.  The  debug  functionality  would  be  supplied  by  the  application  platform  OS  but  not  necessarily 
by  the  Application  Program  Interface  (API.)  Execution  history  would  also  be  maintained  within  the  OS. 

5.  There  is  little  standard  practice  with  respect  to  this  architecture.  It  is,  in  general,  dependent  on 
the  implementation  of  the  test  bed  hardware. 

Given  the  above  characteristics,  the  current  POSIX  primitives  for  process  control  do  not  give  the 
degree  of  control  needed  to  support  the  debug  requirements.  It  would  be  difficult  to  "single-step"  a 
process  with  the  current  services.  In  addition,  full  debug  control  may  require  the  capability  to  override 
normal  operating  system  functions  (i.e.,  scheduling).  It  may  be  required  to  "idle"  a  target  system  so  that  it 
can  be  "patched."  Such  actions  have  an  "anti-operating  system"  viewpoint.  New  POSIX  senrices  (with 
syntax,  semantics,  and  protocols)  would  need  to  be  provided  to  satisfy  the  OCD  requirements.  However, 
such  services  would  need  to  be  privileged  and  not  part  of  the  basic  API  available  to  every  application. 
Execution  history  would  need  to  be  added  to  the  OS  functionality.  Note  that  in  some  systems  debug 
services  are  part  of  the  operating  system  (and  are  removed  in  the  operational  system).  They  may  only  be 
recording  debug  information  that  the  application  accesses  runtime.  In  that  case,  interfaces  such  as  the 
POSIX  read-file  (paragraph  6.4, 1003.1  and  paragraph  6.1, 1003.5)  may  be  adequate. 

Based  on  the  above  discussion,  the  debug  requirement  would  currently  be  supported  by  POSIX 
for  a  number  of  profiles  (although  a  considerable  effort  in  generating  a  debug  application  would  also  be 
necessary)  and  not  supported  by  POSIX  for  other  profiles. 


3.10.1  Debug  Support 

This  unfulfilled  requirement  is  classified  as  "c”  (may  be  deferred). 

Requirement:  The  OSIP  shall  support  the  debugging  of  applications,  specifically  supporting  the 
following  capabilities: 

1.  Examine  registers 

2.  Alter  registers 

3.  Set/clear  breakpoint 

4.  Set/clear  watchpoint 

5.  Single  step  execution 

6.  Continue  execution 

7.  Examine  memory 

8.  Alter  memory 

9.  Query  process  environment 

10.  Query  call  stack 
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Description  of  DeKa:  Depending  on  the  architecture,  there  is  either  no  delta  or  a  considerable 
delta.  POSIX  standards  do  rot  directly  address  application  debugging.  However,  vendors  who  are 
marketing  POSIX-compliant  systems  are  certain  to  include  debugging  support  for  application  developers 
as  part  of  their  system.  POSIX  standards  should  contain  debug  support  to  ensure  that  a  common  set  of 
debug  capabilities  exists  across  different  POSIX-compliant  systems.  At  present,  it  is  unclear  where  debug 
support  should  be  iroluded  in  the  POSIX  standards. 

Resolution  Alternatives: 

1 .  Redefine  the  requirement  so  that  it  is  limited  to  application  platform  resident  debug 
tools.  This  would  eliminate  the  delta.  PSESWG  would  be  responsible  for  standardization  of  the 
resulting  debug  interface  (tool-to-tool,  tool-to-OS,  etc.).  This  seems  contrary  to  the  intent  of  the 
requirement  in  section  4.1.10  of  the  OCD. 

2.  Insert  new  sen^ice  primitives  into  the  POSIX  standard.  Because  there  is  no  standard 
practice  to  support  these  primitives,  both  the  syntax  arxf  semantics  for  them  (in  terms  of  the 
UNIX/C  environment  or  the  Ada  tasking  model)  would  also  have  to  be  determined.  This  alternative 
does  rot  fit  the  NGCR  methodology  of  building  on  current  practice. 

3.  Declare  that  the  OS/PSE  interface  is  not  done  through  the  API  and  thus  is  rot  part  of 
the  MIL-STD-OSIF.  Again,  PSESWG  would  be  responsible  for  defining  and  standardizing  an 
appropriate  OS/PSE  interface  including  potential  communicatton  protocols. 

4.  Wait  for  the  OSSWG/PSESWG  boundary  paper  to  determine  the  scope  of  the 
problem. 

Recommendation:  OSSWG  recommends  alternatives  3  and  4. 


3.10.2  Execution  History 

This  unfulfilled  requirement  is  classified  as  "c”  (may  be  deferred). 

Requirement:  The  OSIF  shall  support  the  ability  to  monitor  the  execution  history  of  a  process, 
including  such  information  as 

1.  Frequency  of  calls 

2.  Len^h  of  calls 

3.  Missed  deadlines 

4.  Length  of  queues 

5.  Tasking  of  mntime  systems 

6.  Dynamic  paging  activity 

7.  Memory  allocation 

8.  What  OS  senrices  being  used 

Description  of  Delta:  An  interface  to  support  the  collection  and  reporting  of  execution  statistics  of 
a  process  is  rot  addressed  in  the  POSIX  standards.  Execution  statistics  are  needed  to  evaluate  and  tune 
process  and  system  performance.  1003.1  would  be  a  logical  place  to  incorporate  an  interface  for  the 
collection  and  reporting  of  execution  statistics  of  a  process. 

An  application  platform  resident  debug  program  could  easily  implement  this  requirement  within  a 
debug  application  "shell.”  Even  if  no  debug  application  is  assumed,  most  of  these  statistics  could  be 
achieved  using  POSIX  service  primitives  within  an  application  (except  for  missed  deadlines).  This 
execution  history  functionality  would  become  the  responsibility  of  the  application  layer  and  rot  readily 
available  to  an  external  PSE.  A  cleaner  solution  would  be  to  enhance  the  "ps"  command  to  include  some 
history  status  as  part  of  its  functionality. 
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RMOkition  Alternatives: 

1 .  Redefine  the  requirement  so  that  it  is  limited  to  application  platform  resident  PSE  tools. 
This  would  eliminate  the  delta.  PSESWG  would  be  responsible  for  standardization  of  the 
resulting  execution  history  tool  interface. 

2.  Modify  the  current  status  service  primitives  in  the  POSIX  standard  to  include  history 
information.  This  would  make  history  information  more  readily  available  to  both  an  application  and 
an  external  PSE. 

3.  Wait  for  the  OSSWG/PSESWG  boundary  paper  to  determine  the  scope  of  the 
problem. 

Recommendation:  OSSWG  recommends  alternatives  2  atxf  3. 


Requirements  Coverage  Summary 


Requirement 

Covered 

POSIX  Delta 

Unfulfilled 

Requirements 

Rating 

10.1 

No 

Insertion 

c 

10.2 

No 

Insertion 

c 

3.11  RELIABILITY,  ADAPTABILITY,  AND  MAINTAINABILITY  INTERFACES 

In  general,  the  POSIX  standards  support  sen/ice  class  11  in  a  rudimentary  way.  There  are  two 
areas  that  are  not  complete: 

1.  Basically  POSIX  provides  reactive  fault  management,  while  OSSWG  requires  proactive 
behavior.  Attempting  to  support  proactive  requirements  on  top  of  a  reactive  interface  will  result  in 
performance  penalties.  The  existing  (proactive)  services  are  highly-oriented  toward  providing  event 
services  (via  the  "signaP  concept),  while  downplaying  fault  reportage. 

2.  POSIX  does  not  provide  adequate  monitoring,  coordination,  and  recording  services. 

For  the  purposes  of  this  subsection,  it  is  important  to  differentiate  modules  of  the  operating 
system  itself  from  modules  that  do  "generalized  input/output.”  The  latter  are  often  called  "device  drivers." 
In  the  latter  case,  it  is  fairly  straightforward  for  an  application  to  provide  all  the  services  specified  by 
O^WG.  For  instance,  an  interface  can  be  added  to  set  a  fault  threshold  for  retrying  a  message 
transmitted  via  a  UHF  radio.  Since  the  provided  functionality  is  under  direct  control  of  the  application  and 
is  not  required  of  the  general  operating  system  (i.e.,  POSIX),  the  potential  functionality  of  application- 
developed  generalized  I/O  modules  will  not  be  further  considered. 

Refer  to  the  Executive  Summary  in  section  3.5  (Event  and  Error  Interfaces)  for  additional 
information  pertinent  to  this  section. 


3.11.1  Fault  Information  Collection 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 

OSSWG  requirement  Fault  Information  Collection  (11.1)  is  partially  covered  by  POSIX.  While  the 
event  interfaces  exist  and  error  interfaces  are  provided  for  individual  processes,  there  are  no  fault 


39 


NAWC  AD  WAR-941 09-70 


coordination  or  distribution  interfaces.  Furthemwre,  an  event  ("signal''  in  POSIX)  can  be  blocked  without 
the  sender's  knowledge  or  any  other  reportage. 

Raquirement:  The  OSIF  shall  provide  for  specifying  the  collection  of  available  fault  information. 

Description  of  Delta:  This  requirement  refers  to  specifying  the  collection  of  fault  information 
coming  into  the  OS  across  the  OSIF  for  subsequent  distribution  according  to  requirement  1 1.2.  POSIX 
says  nothing  about  such  fault  information  collection. 

Recommendation:  OSSWG  recommends  monitoring  and  participating  in  related  standards  efforts 
at  UNIX  International:  Open  Software  Foundation;  POSIX  Services  for  Reliable,  Available,  and  Serviceable 
Systems  group;  and  X3T8.  When  these  groups  develop  mature  standards,  move  appropriate  interfaces 
into  POSIX. 


3.11.2  Fault  Information  Request 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 

OSSWG  requirement  Fault  Information  Request  (11.2)  is  partially  covered  by  POSIX.  While  the 
event  interfaces  exist  and  error  interfaces  are  provided  for  indivkkjal  processes,  there  are  no  fault 
coordination  or  distribution  interfaces.  Furthermcre,  an  event  ("signal”  in  POSIX)  can  be  blocked  without 
the  sender's  knowledge  or  any  other  reportage. 

Refer  to  section  3.5.2  (Event  and  Error  Distribution)  for  additional  information  related  to  Fault 
Information  Request. 

Raquirement:  The  OSiF  shali  provide  for  the  receipt  of  fault  information  on  request. 

Description  of  Delta:  POSIX  provides  for  the  distribution  of  errors  to  the  requesters  of  individual 
functions.  Each  function  specifies  which  errors  ail  POSIX  implementations  must  detect  and  which  are 
optional.  Paragraph  2.4  of  1003.1  lists  the  possible  errors.  However,  "implementations  may  support 
additional  errors  not  included  in  this  clause,  may  generate  errors  included  in  this  clause  urider 
circumstances  other  than  those  described  in  this  clause,  or  may  contain  extensions  or  limitations  that 
prevent  some  errors  from  occurring"  (paragraph  2.4, 1003.1).  "If  more  than  one  error  occurs  in  processing 
a  function  call,  this  part  of  tSO/lEC  9945  does  not  define  in  what  order  the  errors  are  detected;  therefore, 
any  orie  of  the  possible  errors  may  be  returned"  (paragraph  2.4, 1003.1). 

The  OSIF  requires  that  all  possible  fault  information  be  available,  not  just  one  of  the  errors  that 
occurred.  It  also  requires  that  there  be  a  means  for  coordinating  the  distribution  of  fault  information,  as  for 
examf^  to  a  single  process  responsible  for  fault  analysis. 

Recommendation:  OSSWG  recommends  monitoring  and  participating  in  related  standards  efforts 
at  UNIX  International;  Open  Software  Foundation;  POSIX  Services  for  Reliabie,  Available,  and  Serviceable 
Systems  group:  and  X3T8.  When  these  groups  develop  mature  standards,  move  appropriate  interfaces 
into  POSIX. 


3.11.3  Diagnostic  Tests  Request 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 

This  requirement  is  not  supported  by  POSIX. 

Requirement:  The  OSIF  shall  provide  for  the  initiation  of  diagnostic  tests  on  specific  request.  The 
OSIF  shall  support  initiation  of  diagnostic  tests  at  specified  intervals.  This  is  a  necessary  OSIF 
requirement. 
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DescrioMon  of  Delta:  POSiX  does  not  provide  for  the  initiation  of  diagnostic  requests. 

Recommendation:  OSSWG  recommends  monMoring  and  participating  in  related  standarrte  efforts 
at  LMIX  tntemattonal;  Open  Software  Foundation;  POSIX  Services  for  Reliable,  AvaUabie,  and  Serviceable 
Systems  group:  artd  X3T8.  When  these  groups  develop  mature  starKlards.  move  appropriate  intertsK^s 
into  POSIX. 


3.11.4  Diagnostic  Tests  Results 

This  unfulfilled  requirement  is  classified  as  ‘a*  (essential). 

This  requirement  is  not  supported  by  PC^IX. 

Requirement:  The  OSIF  shall  provide  the  ability  to  determine  the  results  of  diagnostic  tests. 

Description  of  Delta:  POSIX  does  not  provide  for  determining  the  results  of  diagnostic  tests. 

Recommendation:  OSSWG  recommends  monitoring  and  participating  in  related  standards  efforts 
at  UNIX  International:  Open  Software  Foundation:  POSIX  Services  for  Reliable.  Available,  and  Serviceable 
Systems  group:  and  X3T8.  When  these  groups  develop  mature  standards,  move  appropriate  interfaces 
into  POSIX. 


3.11.5  Operational  Status 

This  unfulfilled  requirement  is  classified  as  "a"  (esserttial). 

This  requirement  is  barely  supported  by  POSIX. 

Requirement:  The  OSIF  shall  provide  access  to  the  operational  status  of  all  system  components. 

Description  of  Delta:  POSIX  essentially  does  not  provide  access  to  the  status  of  system 
components.  POSIX  does  inform  a  requester  of  the  success  or  failure  of  a  requested  function  from  which 
the  requester  may  derive  some  status  information.  Specifically,  [ENXIO],  no  such  device  or  address,  and 
[EIO],  input/output  error,  are  possible  error  returns  (paragra|3l)  2.4,  1003.1).  However,  in  the  case  of 
[ElOj,  "any  other  error-causing  operation  on  the  same  file  descr^tor  may  cause  the  [EIO]  error  indication 
to  be  lost"  (paragraph  2.4, 1003.1). 

Process  termination  status  is  available  to  an  application  that  has  issued  a  1003.1  waitO  for  a  child 
process  termination. 

Also,  thread  termination  "makes  the  vahre  status  available  to  any  successful  join  with  the 
terminating  thread"  (PI 003.4a). 

Some  systems,  however,  may  maintain  operational  status  in  a  file.  In  that  case  interfaces  such  as 
the  POSIX  read-file  (paragraph  6.4, 1003.1  and  paragraph  6.1, 1003.5)  may  be  adequate  to  obtain  this 
^formation. 

Recommendation:  OSSWG  recommends  monitoring  and  participating  in  related  standards  efforts 
at  UNIX  International;  Open  Software  Foundation;  POSIX  Services  for  Reliable,  Available,  and  Serviceable 
Systems  group:  and  X3T8.  When  these  groups  develop  mature  standards,  move  appropriate  interfaces 
into  POSIX. 
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3.11.6  Fault  Detection  Thresholds 

This  unfulfilled  requirement  is  classified  as  "a*  (essential). 

An  application  can  choose  to  retry  an  operation,  as  specified  by  requirement  11.6,  but  retries  are 
risky  skice  the  state  of  the  operating  system  is  not  well-defined  subsequent  to  an  error.  Furthermore,  no 
other  part  of  requirement  1 1 .6  (fault  detection  thresholds),  such  as  classifying  the  component  as  suspect, 
is  provided. 

Requirement:  The  OSIF  shall  provide  for  specifying  fault  detection  thresholds,  which  shall 
include,  but  not  be  limited  to,  the  following: 

1 .  Number  of  retry  attempts,  if  applicable,  that  shall  be  made  before  an  error  is  determined 

to  be  a  non  recoverable  fault. 

2.  Maximum  number  of  correctable  errors  that,  if  detected  within  a  specified  time,  win 

c  .  y  the  component  as  suspect  or  treat  the  collective  errors  as  a  non  recoverable  fault. 

Description  of  Delta:  Within  the  limits  discussed  under  requirement  5.2  -  i.e..  POSIX  does  rK>t 
provide  for  coordination  in  the  distribution  of  events  and  errors  -  some  user-selectable  error  processing 
alternatives  are  available.  Processes  can  mask  signals  (paragraph  3.3.1 .2. 1003.1).  Processes  can  also 
choose  among  three  types  of  actions  that  they  can  associate  with  a  signal:  a  default  action,  ignore,  and  a 
signal  catching  function  (paragraph  3.3.1 .3,  1003.1).  Retries  and  accumulation  of  occurrences  would 
then  be  the  responsibility  of  the  individual  processes.  In  particular,  occurrences  of  a  particular  event  or 
error  could  not  be  collected  for  several  processes  or  for  the  system  as  a  whole  through  the  interface.  This 
discussion  also  applies  to  threads  as  per  Pi  003.4a  signal  handling. 

Recommendation:  OSSWG  recommends  monitoring  and  participating  in  related  standards  efforts 
at  UNIX  International:  Open  Software  Foundation;  POSIX  Sen/iCes  for  Reliable,  Available,  and  Senriceabie 
Systems  group:  and  X3T8.  When  these  groups  develop  mature  standards,  move  appropriate  interfaces 
into  POSIX. 


3.11.7  Fault  Isolation 

This  unfulfilled  requirement  is  classified  as  *a"  (essential). 

This  requirement  is  barely  supported  by  POSIX. 

Requirement:  The  OSIF  shall  support  the  isolation  of  faults  to  a  particular  component. 

Description  of  Delta:  POSIX  provides  little  support  for  the  isolation  of  faults,  either  in  the  sense  of 
precisely  determining  the  component  causing  the  fault  or  in  the  sense  of  containing  the  fault  to  prevent  it 
from  damaging  the  rest  of  the  system,  which  assumes  determining  the  source  of  the  fault. 

Using  error  numbers  from  failed  function  calls  to  determine  the  responsible  component  is 
unsatisfactory  because  "if  more  than  one  error  occurs  in  processing  a  function  call,  this  part  of  ISO/IEC 
9945  does  not  define  in  what  order  the  errors  are  detected:  therefore,  any  one  of  the  possible  errors  may 
be  returned”  (paragraph  2.4, 1003.1).  Furthermore,  error  numbers  do  not  provide  enough  information  as 
to  the  nature  of  the  error.  For  instance,  POSIX  may  return  [ENXIO]  when  a  device  does  not  exist,  a 
request  was  made  beyond  the  limits  of  the  device,  or  a  tape  drive  is  not  online  or  a  disk  pack  is  not  loaded 
on  a  drive  (paragraph  2.4, 1003.1).  A  prerequisite  to  fulfilling  this  requirement  is  to  also  fulfill  requirements 
11.3  and  11.4  to  determine  faulty  components  and  requirement  11.10  to  prevent  a  faulty  component 
from  causing  further  damage. 

Device  Control  (PI 003.4b)  may  permit  device  fault  isolation,  but  is  not  required  to  do  so. 

If  requirement  5.1  is  fully  satisfied,  mechanisms  will  be  available  to  support  fault  isolation. 
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Rflcommendation:  OSSWG  recommends  monMoring  and  participating  in  related  standards  efforts 
at  UNIX  International;  Open  Software  Foundation;  POSIX  Services  for  Reliable,  Available,  and  Serviceable 
Systems  group;  and  X3T8.  When  these  groups  develop  mature  standards,  move  appropriate  interfaces 
into  POSIX. 


3.11.8  Fault  Response 

This  unfulfilled  requirement  is  classified  as  ‘a*  (essential). 

11’=''  requirement  is  barely  supported  by  POSIX. 

Requirement:  The  OSIF  shall  specify  the  actions  to  be  taken  on  the  occurrence  of  a  fault.  The 
OSIF  shall  support  (at  least)  the  following  actions: 

1 .  Restart  at  a  specified  point  for  a  specified  fault. 

2.  Use  of  specified  com^nents  as  backup  for  faulty  components. 

3.  Stop  when  a  specified  minimum  set  of  components  is  no  longer  available. 

4.  Schedule  of  a  specified  process. 

5.  Report  to  another  node. 

Description  of  DeKa:  Within  the  limits  discussed  under  requirement  5.2  •  i.e.,  POSIX  does  not 
provide  for  coordination  in  the  distribution  of  events  and  errors  •  some  user-selectable  error  processing 
altematives  are  available.  Processes  can  mask  signals  (paragr^h  3.3.1.2, 1003.1).  Processes  can  also 
choose  between  three  types  of  actions  that  they  can  associate  with  a  signal:  a  default  action,  ignore,  and  a 
signal  catching  function  (paragraph  3.3.1 .3.  1003.1).  Restart,  stop  (provided  retirement  11.5  is 
fulfilled),  schedule,  and  report  actions  would  then  be  the  responsibility  of  the  individual  processes. 
Directing  the  use  of  specific  hardware  components  is  not  a  function  of  POSIX.  Consistent  handling  of  a 
particular  fault  would  not  be  a  function  of  the  interface  but  would  have  to  be  a  design  convention  for  each 
system.  This  discussion  also  applies  to  threads  as  per  Pi  003.4a  signal  handling. 

Recommendation:  OSSWG  recommends  monitoring  and  participating  in  related  standards  efforts 
at  UNIX  international;  Open  Software  Foundation;  POSIX  Services  for  Reliable.  Available,  and  Senriceabie 
Systems  group;  and  X3T8.  When  these  groups  develop  mature  standards,  move  appropriate  interfaces 
into  POSIX. 


3.11.9  Reconfiguration 

This  unfulfilled  requirement  is  classified  as  "a”  (essential). 

This  requirement  is  barely  supported  by  POSIX. 

Requirement:  The  OSIF  shall  support  the  dynamic  reconfiguration  of  hardware  and  software. 

Description  of  Delta:  POSIX  does  not  support  reconfiguration  of  hardware  and  does  not  explicitly 
support  reconfiguration  of  software.  POSIX  does  provide  ways  to  create  and  terminate  processes. 
1(>03.1  allows  processes  to  spawn  and  execute  child  processes  and  to  effect  normal  and  abnormal 
termination  of  processes .  Pi 003.4a  expands  this  capability  to  also  allow  for  the  creation,  termination,  and 
canceHation  of  threads,  though  currently  a  thread  cannot  be  unconditionally  terminated  by  another  thread. 
Thus,  a  mechanism  external  to  the  OS  and,  therefore,  not  included  as  such  in  the  OSIF,  such  as  an  overall 
"parent”  process  or  processes  responsible  for  software  configuration,  could  answer  the  software 
reconfiguration  part  of  this  requirement.  Again,  because  POSIX  does  not  provide  for  the  centralization  of 
such  functions  within  a  system,  effecting  software  reconfiguration  in  this  manner  may  rec^ire  extensive 
management  and  coordination,  particularly  between  processes,  during  system  development  and  be 
unique  to  each  system  developed. 
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Some  systems  may  only  require  a  more  rudimentary  form  of  recortfiguration  whereby  the  new 
configuration  is  recorded  in  a  file.  Then,  either  the  operatiiig  system  monitors  the  file  and  ^ects  the 
reconfiguration  and/or  the  application  directs  a  reboot  of  the  system  which  effects  the  reconfiguration.  In 
such  a  case  reconfiguration,  as  far  as  the  application  is  concerned,  can  be  realized  through  inierfaces 
such  as  the  POSIX  write-file  (paragraph  6.4, 1003.1  and  paragraph  6.1, 1003.5). 

Recommendation:  OSSWG  recommends  monttoring  and  partic^ating  in  related  standards  efforts 
at  UNIX  International;  Open  Software  Foundation;  POSIX  Services  for  Reliable,  Available,  and  Serviceable 
Systems  group;  and  X3T8.  When  these  groups  develop  mature  standards,  rTx>ve  appropriate  interlaces 
into  POSIX. 


3.11.10  Enable/Disable  System  Component 

This  unfulfilled  requirement  is  classified  as  ”a*  (essential). 

POSIX  coverage  of  requirement  11.10  (Enabie/Oisable  System  Component)  is  also  unacceptably 
poor,  even  though  it  does  provide  some  of  the  functionality  demanded  by  OSSWG.  In  particular,  POSIX 
permits  a  component  to  be  terminated  if  (1 )  the  unit  to  be  terminated  is  a  software  "process,'’  and  (2)  the 
process  correctly  receives  and  handles  a  "signal  kill." 

Requirement:  The  OSIF  shall  provide  the  ability  to  enable  or  disable  a  specified  system 
component  on  request. 

Description  of  Delta:  POSIX  does  not  provide  the  ability  to  enable  or  disable  hardware 
components,  although  I/O  work  in  1003.7  and/or  the  Device  Control  interface  in  PI  003.4b  may  apply. 
POSIX  does  provide  ways  to  create  and  terminate  processes.  1003.1  allows  processes  to  spawn  and 
execute  child  processes  (paragraph  3.1)  and  to  effect  normal  and  abnormal  termination  of  processes 
(paragraphs  3.2  and  3.3).  P1003.4a  expands  this  capability  to  also  allow  for  the  creation,  tenninatton.  and 
cancellation  of  threads,  though  currently  a  thread  cannot  be  unconditionally  terminated  by  another  thread. 

Recommendation:  OSSWG  recommends  monitoring  and  participating  in  reiated  standards  efforts 
at  UNIX  International;  Open  Software  Foundation;  POSIX  Services  for  Reliable,  Available,  and  Serviceable 
Systems  group;  and  X3T8.  When  these  groups  develop  mature  standards,  move  appropriate  interfaces 
into  POSIX. 


3.11.11  Performance  Monitoring 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 

A  few  performance  statistics  are  available  from  POSIX.  For  instance,  a  process  can  measure  its 
CPU  time  and  some  information  about  its  file  utilization.  But  otherwise  POSIX  does  not  meet  the 
performance  monitoring  requirement,  11.1 1. 

Requirement:  The  OSIF  shall  support  queries  for  snapshots  of  resource  utilization  and  enabling 
or  disabling  rmnitoring  of  each  resource. 

Description  of  Delta:  POSIX  provides  limited  support  for  obtaining  snapshots.  1003.1  provides 
for  obtaining  process  and  child  process  execution  and  system  CPU  times  and  1 003.4b  provides 
interfaces  for  otrtaining  execution  times  of  an  arbitrary  process  or  thread.  1003.1  also  provides  for 
obtaining  file  information  including  time  of  the  last  access,  time  of  the  last  data  modification,  and  time  of  the 
last  file  status  change . 

Recommendation:  OSSWG  recommends  monitoring  and  participating  in  related  standards  efforts 
at  UNIX  International;  Open  Software  Foundation;  POSIX  Services  for  Reliable,  Available,  and  Senriceable 
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Systems  group;  and  X3T8.  When  these  grou{»  develop  mature  standards,  move  appropriate  interfaces 
mtoPOSIX. 


3.11.12  Set  Resource  Utilization  Limits 

This  requirement  is  directly  met  by  PI  003.1  a  Resource  Limits,  the  numerical  limits  defined  by 
1003.1  and  its  amending  documertts,  and  the  Sporadic  Server  and  CPU  Time  Clocks  of  Pi  003.4b. 


3.11.13  Resource  Utilization  Limits  Violation 

This  requirement  is  directly  met  by  P1003.1a  Resource  Limits  and  the  error  returns  in  1003.1  and 
its  amending  documents  which  indicate  that  one  of  the  numerical  limits  has  been  exceeded. 


3.11.14  Checkpoint  Data  Structures 

Requirement  Checkpoint  Data  Structure  (11.14)  is  completely  met  by  P1003.1a  Checkpoint  a 
Process  or  Set  of  Processes  alortg  with  Restart  Execution  of  a  Process  or  Process  Family. 

It  should  be  noted  that  the  Checkpoint  functbn  saves  all  the  process  state  information  necessary 
to  restart  a  process  or  family  of  processes.  Particularfy  if  a  system  needs  to  checkpoint  ordy  data  structures 
or  only  certain  data  structures,  other  interfaces  to  consider  are  the  Memory  Mapping  interfaces  in  1003.4 
and  PI 003.20.  Memory  Mapping  allows  an  application  to  establish  a  mapping  between  a  part  of  the 
process  address  space  and  a  memory  obje^  suct«  as  a  file  on  a  storage  medium.  If  the  application 
chooses  a  map-shared  option  for  use  with  this  interface,  write  references  to  the  specified  address  space 
will  also  chan^  the  file  on  the  storage  medium.  Mematively  the  application  may  request  a  Synchronize 
function  at  its  own  discretion  which  updates  the  file  to  agree  with  the  specified  address  space. 
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3.12  RESOURCE  MANAGEMENT  INTERFACES 

This  service  ciass  is  partially  supported  by  1003.1, 1003.4,  and  P1003.7. 


3.12.1  Virtual  Memory  Support 

This  unfulfilled  requirement  is  classified  as  "a*  (essential). 

Requirement:  The  OSIF  shall  support  the  selection  of  the  virtuai  memory  utiiization  parameters. 

Description  of  Delta:  This  requirement  refers  to  controlling  virtual  memory  utilization  such  as  the 
paging  algorithm.  POSIX  Pi 003.4b  provides  an  Advisory  Information  interface,  rriadvise(),  which  advises 
the  operating  system  of  the  application's  expected  memory  access  behavior.  However,  this  information  is 
purely  advisory,  and  may  not  provide  sufficient  control  over  virtual  memory  parameters  for  some  realtime 
applications. 

Resolution  Altematives: 

1.  Enhance  existing  POSIX  interfaces  to  include  this  capability.  There  has  historically 
been  much  opposition  within  POSIX  to  the  inclusion  of  interlaces  that  place  requirements  on  the 
underlying  architecture.  Opponents  argue  that  applications  that  presume  a  particular  method  of 
memory  management  will  not  be  portable  to  all  architectures.  Vendors  who  do  not  support  virtual 
memory  architectures  would  be  undesirably  forced  to  provide  such  a  function.  The  requirement 
for  such  an  interface  might  also  inhibit  the  development  of  new  and  better  methods  of  memory 
management.  Typically,  UNIX  operating  systems  from  vendors  that  support  virtual  memory,  do 
provide  limited  control  over  the  use  of  virtuai  meny)ry.  The  HP-UX  chatr()  command  is  a  good 
example.  A  complete  virtual  memory  support  interlace  would  best  be  added  to  PI  003.7.  Even 
though  1003.2  might  also  be  a  logical  place  for  such  an  interface,  OSSWG  has  chosen  to  avoid 
inclusion  of  1003.2  in  the  OSIF  primarily  for  performance  reasons. 

2.  Assume  a  standard  outside  POSIX.  Often,  the  link  editor  has  options  that  allow  for 
some  control  over  a  process's  use  of  virtual  memory.  The  C  or  Ada  standard  might  include  options 
to  allow  selection  of  virtual  memory  characteristics.  These  would  be  embedded  in  the  executable 
header  information  similar  to  the  link  editor  in  HP-UX. 

3.  Develop  a  new  military  standard.  This  is  a  less  acceptable  alternative  than  1  because  it 
is  external  to  the  OSIF  baseline,  it  is  suggested  that  any  new  military  standard  be  based  on  de 
facto  UNIX  or  industry  standard(s),  if  any  exist. 

Recommendation:  The  PI  003.7  group  should  be  approached  with  the  possibility  of  adding  a 
virtual  memory  support  interface.  A  sample  interface  could  be  drafted  using  HP-UX  chatr()  command  as  an 
example.  If  the  first  approach  fails  due  to  lack  of  suji^rt,  then  the  interface  should  be  added  to  the  military 
standard.  Consideration  should  be  given  to  making  the  interface  optional  based  on  arguments  outlined 
under  alternative  1  above. 


3.12.2  Virtual  Space  Locking 

The  requirement  for  Virtual  Space  Locking  (12.2)  is  directly  met  by  the  1003.4  Memory  Locking 
functions. 


3.12.3  Dynamic  Memory  Allocation  and  Deallocation 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 
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Requirement:  The  OSIF  shall  provide  for  allocation  of  a  block  of  virtual  or  physical  memory  of  the 
size  spectfled  and  for  deallocation  of  a  previously  allocated  block.  Note  that  this  requirement  has  particular 
relevance  for  Ada  applications,  as  specified  in  paragraph  3.16.15.  Changes  to  the  recommendations 
should  take  that  fact  into  account. 

Descrtotion  of  Delta:  Memory  management  was  purposely  omitted  as  a  separate  1003.1  function. 
Instead,  it  is  included  in  Section  8  of  1003.1-1990  as  part  of  the  standard  by  virtue  of  being  embodied  in  C 
language  functions  such  as  calloc,  malloc,  realloc,  and  free.  Thus,  1003.1  relies  on  the  language  to 
provide  memory  management.  However,  it  has  become  standard  practice,  considering  the  fact  that  most 
systems  support  shared  memory  and  memory  of  several  different  types,  to  utilize  the  1003.4  facilities  of 
Memory  Mapped  RIes  to  support  memory  allocation.  Specifically,  the  1003.4  mmap()  function  may  be 
applied  to  a  descr^or  obtained  by  opening  a  special  name  associated  with  an  allocator  for  a  given  type  of 
memory;  such  a  call  then  allocates  the  requested  amount  of  that  type  of  memory  and  returns  a  handle  to 
that  memory.  The  munmap()  function  provides  the  ability  to  deallocate  memory  allocated  in  this  way. 
P1003.4d  will  specify  these  additional  semantics  plus  additional  interfaces  necessary  for  use  of  1003.4 
mmap()  and  munmap()  in  this  way,  including  the  ability  to  allocate  and  share  typed  memory. 

Resolution  Alternatives: 

1.  Enhance  existing  POSIX  interfaces  to  include  this  capability.  A  chapter  for  Pl003.4d 
which  will  provide  this  cap^ility  has  been  drafted.  Therefore,  the  obvious  approach  is  to  closely 
monitor  this  chapter  to  ensure  that  it  continues  to  support  the  allocation  OSSWG  requires;  when 
the  chapter  becomes  stable,  it  will  be  entered  into  the  draft,  and  the  requirement  will  then  be  met 
by  P1003.4d. 

Recommendation:  OSSWG  should  continue  to  support  the  efforts  to  complete  the  Typed 
Memory  interfaces  in  P1003.4d. 


3.12.4  Dynamically  Protecting  Memory 

This  unfulfilled  requirement  is  classified  as  "a”  (essential). 

Requirement:  The  OSIF  shall  provide  the  ability  to  query  and  set  memory-protection  attributes. 

Description  of  Delta:  The  POSIX  standard  provides  dynamic  memory  protection  for  shared 
memory  through  the  open()  interface  in  1003.4.  The  protection  can  be  changed  at  runtime  by  closing  and 
reopening  the  shared  memory  connection.  There  is  no  provision  for  protection  of  arbitrary  blocks  of 
memory  or  when  allocating  dynamic  memory.  P1003.4d  contains  a  draft  chapter  for  Typed  Memory 
allocation  implemented  via  mmap().  Since  there  is  already  control  of  mapped  memory  protection  for  all 
objects  mapped  via  mmap(),  this  requirement  will  be  directly  met  once  the  Typed  Memory  chapter  of 
P1003.4d  is  approved  by  the  working  group. 

Resolution  Alternatives: 

1.  Enhance  existing  POSIX  interfaces  to  include  this  capability.  POSIX  only  provides  for 
the  protection  of  mapped  or  shared  memory.  There  are  no  POSIX  interface  to  query  or  set  the 
memory  protection  attributes  of  other  types  of  memory.  The  PI  003.1a  standards  group  has  been 
discussirig  this  issue.  The  1003.4  group  has  drafted  a  chapter  for  Pl003.4d  which  provides  for 
Typed  Memory  allocation  and  associated  protection  via  mma^)  and  mprotect(}. 

2.  Develop  a  new  military  standard.  It  is  suggested  that  the  interface  be  modeled  after  the 
Memory  Locking  interface  in  1003.4  or  on  de  facto  UNIX  or  industry  standard(s),  if  any  exist. 

Recommendation:  Continue  to  support  adoption  of  the  P1003.4d  Typed  Memory  allocation 
capabilities. 
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3.12.5  Shared  Memory 

This  unfulfilled  requirement  is  classified  as  *b’  (highly  desirable). 

Requirement:  The  OSIF  shall  support  concurrent  access,  by  several  processes,  to  specified 
areas  of  physical  memory,  whether  or  not  the  involved  processes  exist  on  a  single  processor  or  multiple 
processors. 

Description  of  Delta:  POSIX  1003.4  provides  a  set  of  interfaces  for  creating,  attaching  to,  and 
deleting  shared  data  regions.  The  requirement,  however,  specifies  that  both  the  data  and  the  code 
regions  need  to  be  shared.  The  ability  to  share  code  is  useful  for  libraries  and  certain  utilities  and  could  be 
a  pre-runtime  interface.  Even  though  it  is  not  explicitly  stated  that  multi  processor  shared  memory  is 
supported,  there  is  nothing  in  the  stand.i'd  that  precludes  it. 

POSIX  also  provides  several  interface  alternatives  for  resolving  contention  during  access  to 
shared  memory.  These  include  Counting  Semaphores  in  1003.4  and  PI  003.20,  and  Mutexes  and 
Condition  Variables  in  PI  003.4a.  Mutexes  and  Condition  Variables  were  designed  particularly  for 
processes  that  share  memory.  The  POSIX  Standardized  Profile  for  Multiprocessirig  Systems  (1003.14) 
has  also  proposed  Reader/Writer  Lock  and  Spin  Lodr  interfaces.  Since  1003.14  is  a  profile,  it  can  not 
specify  interfaces  that  are  not  defined  in  other  standards.  However,  1003.4d  is  considering  inclusion  of 
these  interfaces  in  its  specification. 

Resolution  Alternatives: 

1.  Enhance  existing  POSIX  interfaces  to  include  this  capability.  The  POSIX  shared  data 
interfaces  are  found  in  the  1003.4  standard.  There  is  no  interface  to  specify  shared  code.  The 
HP-UX  operating  system  provides  an  interface  to  specify  code  as  sharable.  it  is  the  same  chatr() 
command  referenced  in  3.12.1.  The  most  logical  place  for  this  type  of  interface  seems  to  be 
P1003.7. 

2.  Develop  a  new  military  standard.  It  is  suggested  that  any  new  military  standard  be 
based  on  de  facto  UNIX  or  industry  standard(s),  if  any  exist. 

Rflcommandation:  Recommend  that  this  requirement  be  linked  with  requirement  12.1  arxl 
presented  to  the  Pi  003.7  standards  group.  The  HP-UX  chatr()  interface  could  be  used  as  an  example. 


3.12.6  Allocate,  Deallocate,  Mount,  and  Dismount  Services 

This  unfulfilled  requirement  is  classified  as  "a”  (essential). 

The  requirement  for  Allocate,  Deallocate,  Mount,  and  Dismount  Services  (12.6)  is  partially 
covered  by  the  1003.1  Control  Operations  on  Files  (file  descriptors). 

Requirement:  The  OSIF  shall  support  the  allocation  of  devices  to  processes  and  subsequent 
deallocation  of  these  devices.  For  devices  with  removable  media,  the  OSIF  shall  also  support  mounting 
and  dismounting  of  media. 

Description  of  Delta:  1003.1  provides  allocate  and  deallocate  functionality  through  the  fcntl() 
interface.  POSIX  does  not  yet  provide  mount/dismount  functionality.  Refer  to  3.7.10  for  further 
discussion  of  this  delta. 

Resolution  Alternatives:  Same  as  requirement  7.10. 

Recommendation:  Same  as  requirement  7.10. 


48 


N  AWC  ADWAR-941 09-70 


3.12.7  Designate  Control 

This  unfulfilled  requirement  is  classified  as  'b*  (highly  desirable). 

Requirement:  The  OSIF  shall  provide  the  means  to  designate  responsibility  for  maintaining  the 
status  and  determining  the  configuration  of  a  system  resource.  This  requirement  was  reevaluated  by  a 
small  group,  which  decided  that  it  was  *b‘  (highly  desirable). 

Description  of  Delta:  There  is  no  provision  in  POSIX  for  designating  control  of  system  resources. 

Resolution  Alternatives: 

1.  Change  wording  of  the  OCD  to  read  "shall  support”  instead  of  "shall  provide.” 
Requirement  can  then  be  satisfied  by  the  fork(),  exec(),  and  kill()  interfaces  in  the  1003.1 
standard. 

2.  Enhance  existing  POSIX  interfaces  to  include  this  capability.  This  requirement  is  similar 
to  7.1  device-driver  availability  .  OSSWG  recommended  that  these  requirements  be  pursued  in 
the  1003.4  or  1003.7  standards  groups.  Could  combine  12.7  with  solution  to  7.1.  Any  solution 
needs  to  be  compatible  with  solution  to  12.8  release  control. 

Recommendation:  Recommend  this  requirement  be  pursued  with  7.1,  and  12.8  OSSWG 
requirements  in  1003.4  or  1003.7  standards  groups. 


3.12.8  Release  Control 

This  unfulfilled  requirement  is  classified  as  "b”  (highly  desirable). 

Requirement:  The  OSIF  shall  provide  the  means  to  release  a  previously  assumed  system 
resource  status  and  configuration  responsibility.  This  requirement  was  reevaluated  by  a  small  group, 
which  decided  that  it  was  ”b"  (highly  desirable). 

Description  of  Delta:  See  3.12.7. 

Resolution  Alternatives:  See  3.12.7. 

Recommendation:  See  3.12.7. 


3.12.9  Allocate  Resource 

This  unlulf illed  requirement  is  ctassif ied  as  "a"  (essential) . 

Requirement:  The  OSIF  shall  provide  a  means  to  designate  particular  process  resources  for  use 
by  a  part'KXilar  process. 

Description  of  Delta:  There  is  no  provision  in  POSIX  for  allocating  resources.  Examples  of  units  of 
system  resources  are  I/O  channel,  a  block  of  physical  memory,  response  to  specific  class  of  hardware 
interrupt,  a  breakpoint  register,  a  co-processor  user  identifier,  and  a  connection  over  a  LAN. 

Resolution  Alternatives: 

1.  Enhance  existing  POSIX  interfaces  to  include  this  capability.  Typically,  UNIX  resources 

such  as  files,  devices,  and  network  connections  have  been  referred  to  under  the  general 
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description  of  a  file.  A  logical  to  physical  connection  is  created  and  referenced  by  a  file  descriptor. 
The  same  concept  could  be  extended  to  include  a  number  of  different  resources,  particularly  the 
ones  of  interest  to  OSSWG.  The  new  interface(s)  could  be  added  to  PI 003. la  or  1003.4. 

2.  Develop  a  new  military  standard.  This  is  a  less  acceptable  alternative  than  1  because  it 
is  external  to  the  OSIF  baseline.  It  is  suggested  that  any  new  military  standard  be  based  on  de 
facto  UNIX  or  industry  standard(s),  if  any  exist. 

Recommendation:  Recommend  that  Pi  003.1  a  and  1003.4  be  approached  about  extending 
definition  of  file  to  include  all  resources  needed  by  OSSWG  and  provide  interfaces  to  open,  close,  and 
lock  these  resources.  OSSWG  needs  to  be  more  specific  on  the  scope  of  this  requirement.  The  same 
resolution  should  be  applied  to  requirement  12.10. 


3.12.10  Deallocate  Resource 

This  unfulfilled  requirement  is  classified  as  ’a"  (essential). 

Requirement:  The  OSIF  shall  provide  a  means  to  relinquish  particular  process  resources  from  a 
particular  process. 

Description  of  Delta:  See  3.12.9. 

Resolution  Atternatives:  See  3.12.9. 

Recommendation:  See  3.12.9. 


3.12.11  System  Resource  Requirements  Specification 

This  unfulfilled  requirement  is  classified  as  'b*  (highly  desirable). 

Requirement:  The  OSIF  shall  provide  the  ability  to  specify  system  resource  requirements.  This 
requirement  was  reevaluated  by  a  small  group,  which  decided  that  it  was  ”b"  (highly  desirable). 

Description  of  Delta:  There  is  no  provision  in  POSIX  for  specifying  system  resource  requirements. 

Resolution  Alternative.*;: 

1 .  Enhance  existing  POSIX  interfaces  to  include  this  capability.  The  concept  of  system 
resource  requirements  specification  is  not  presently  In  any  of  the  POSIX  standards.  The  PI  003.7 
group  would  probably  be  the  most  receptive  to  the  addition  of  an  interface  of  this  type. 

2.  Develop  a  new  military  standard.  This  is  a  less  acceptable  alternative  than  1  because  it 
is  external  to  the  OSIF  baseline.  It  is  suggested  that  any  new  military  standard  be  based  on  de 
facto  UNIX  or  industry  standard(s),  if  any  exist. 

3.  Submit  a  new  POSIX  PAR  (System  Resource  Management)  to  do  this  work. 

Recommendation:  The  1003.7  group  should  be  approached  with  the  possibility  of  adding  a 
system  resource  requirements  specification  interface.  A  sample  interlace  could  be  drafted  from  examples 
from  other  operating  systems  that  provided  this  functionality  in  a  more  complete  manner.  A  backup 
position,  should  1003.7  be  unable  or  unwilling  to  take  on  this  interface,  would  be  alternative  3, 
submission  of  a  new  PAR  for  System  Resource  Management. 
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3.12.12  System  Resource  Capacity 

This  unfulfilled  requirement  is  classified  as  ‘b*  (highly  desirable). 

Requirement:  The  OSIP  Shall  provide  a  c^ery  of  the  storage  or  workload  capacities  the  system 
resources.  This  requirement  was  reevaluated  by  a  small  group,  which  decided  that  it  was  t)*  (highly 
desirable). 

PescricitiQn  of  Delta:  There  is  no  provision  in  POSIX  for  specifying  system  resource  capacity. 
P1003.4d  Typed  Memory  interfaces,  when  drafted,  may  allow  applications  to  ^ery  a  typed  memory  pool 
for  the  maximum  amount  of  memory  which  can  be  allocated;  However,  this  is  unique  to  typed  memory 
pool  resources,  not  a  generalized  capability. 

Resolution  Alternatives: 

1.  Enhance  existing  POSIX  interfaces  to  include  this  capability.  The  system  resource 
capacity  requirement  is  provided  by  the  1003.2  standard  in  an  incomplete  way  through 
commands  such  as  du  and  df.  OSSWG  has  chosen  to  avoid  inclusion  of  1003.2  in  the  OSIP.  The 
PI  003.7  group  would  probably  be  the  most  receptive  to  the  addition  of  an  interface  of  this  type. 

2.  Develop  a  new  military  standard.  This  is  a  less  acceptable  alternative  than  1  because  it 
is  external  to  the  OSIP  baseline.  It  is  suggested  that  any  new  military  starxfard  be  based  on  de 
facto  UNIX  or  industry  standard(s),  if  any  exist. 

3.  Submit  a  new  POSIX  PAR  (System  Resource  Management)  to  do  this  work. 

Recommendation:  The  1003.7  group  should  be  approached  with  the  possibility  of  adding  a 
system  resource  capacity  interface.  A  sample  interface  could  be  drafted  using  1003.2  examples  and 
examples  from  other  operating  systems  that  provided  this  functionality  in  a  more  complete  manner.  A 
backup  position,  should  1003.7  be  unable  or  unwilling  to  take  on  this  interface,  would  be  alternative  3, 
submission  of  a  new  PAR  for  System  Resource  Management.  OSSWG  should  continue  to  support  the 
drafting,  refinement,  and  balloting  of  the  P1003.4d  Typed  Merrxjry  facilities. 
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3.13  SYNCHRONIZATION  AND  SCHEDULING  INTERFACES 

In  general,  the  POSIX  standards  support  senrice  class  13  synchronous  and  scheduling  interfaces 
in  a  substantially  complete  way. 


3.13.1  Process  Synchronization 

The  requirements  for  Process  Synchronization  (13.1)  are  directly  met  by  1003.4,  Pi  003.4a  and 
PI  003.4b.  Rhreads  appears  to  fully  satisfy  this  requirement  by  providing  mutex  and  condition  variable 
primitives  for  synchronization  among  threads  within  the  same  process.  This  includes  semaphores, 
signals,  events,  message  queues,  etc.,  for  synchronization  among  threads  in  different  processes. 


3.13.2  Mutual  Exclusion 

The  requirements  for  Mutual  Exclusion  (13.2)  are  fully  met  by  1003.1,  1003.4,  P1003.4a,  and 
Pl003.4b.  Both  mutexes  and  semaphores  support  mutual  exclusion  among  cooperating  processes 
and/or  cooperating  threads,  and  PI  003.4b  extends  both  of  these  such  that  the  waits  may  time  out.  Lock 
files  are  supported  by  the  1003.1  open()  interface. 


3.13.3  Cumulative  Execution  Time  of  a  Process 

The  requirements  for  Cumulative  Execution  Time  of  a  Process  (13.3)  are  directly  met  by  1003.1 
Process  Times  and  PI  003.4b  CPU  Time  Clocks. 


3.13.4  Attach  a  Process  to  an  Event 

This  requirement  is  directly  met  by  1003.1  Signals  as  extended  by  1003.4  to  Queued  Signals  and 
as  further  extended  by  PI 003.4a  to  operate  in  a  multi-threaded  process;  and  by  PI  003.4b  Interrupt 
Control  interfaces. 


3.13.5  Services  Scheduling  Information 

This  unfulfilled  requirement  is  classified  as ’d”  (re-evaiuate). 

The  requirement  for  services  scheduling  information  (13.5)  is  not  supported  by  the  POSIX 
standards  at  all. 

Requirement:  The  OSIF  shall  support  the  ability  for  a  process  to  specify  its  performance 
requirements  for  services. 

Description  of  Delta:  This  requirement  implies  that,  in  order  to  guarantee  timely  completion  of  a 
complex  service  across  a  distributed  system,  the  application  requires  an  upper  bound  on  time  for  that 
service.  This  is  seen  as  similar  to  the  "time-value”  function  associated  with  a  service  interface  in  operating 
systems  such  as  Alpha.  Such  a  function  senres  to  define  the  urgency  of  a  particular  request  separately 
from  the  CPU  scheduling  policy  for  the  requesting  process.  Currently,  OSSWG  does  not  perceive  this 
issue  as  being  addressed  by  any  POSIX  working  group. 

Resolution  Alternatives: 

1.  Enhance  existing  POSIX  interfaces  to  include  this  capability.  This  may  already  be 

possible  due  to  the  open  nature  of  the  1003.4  and  1003.4a  process/thread  scheduling 

interfaces;  that  is,  K  a  new  scheduling  policy  could  be  defined  in  which  a  process  could  maintain  a 
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transaction  scheduling  attribute,  and  if  this  policy  were  included  among  the  selectable  policies, 
the  requirement  might  be  satisfied.  Because  such  a  policy  may  not  be  well  understood  by  the 
industry,  POSIX  has  decided  to  leave  such  a  policy  out  of  the  standards  for  now,  while  leaving  a 
method  for  its  future  insertion. 

Also,  1003.11  needs  to  be  further  queried  to  determine  if  this  capability  conforms  to  its 
charter,  since  outside  of  1003.11,  most  interlaces  do  not  address  the  special  needs  of  atomic 
transactions,  especially  over  a  distributed  network.  Therefore,  it  might  be  more  appropriate  that 
such  transactions  be  addressed  by  1003.11  rather  than  1003.4.  This  is  the  most  suttable 
aitemative  because  the  need  for  this  has  already  been  recognized  by  VITA  and  by  several  other 
vendors. 

2.  Assume  a  standard  outside  of  POSIX.  It  is  difficult  to  understand  the  scope  (rf  this 
requirement  sufficiently  to  rule  out  various  higher  level  distributed  processing  interfaces  built  on 
top  of  existing  operating  systems,  such  as  ISIS.  However,  as  stated,  it  seems  to  imply  a  bounded 
time  that  could  be  achieved  only  if  the  POSIX  kernel  were  cooperating. 

Recommendation:  OSSWG  recommends  aitemative  1.  However  the  1003.11  working  group  has 
been  dissolved  and  cannot  be  used  to  resolve  this  delta.  Furthermore,  the  1003.4  working  group  has 
rejected  this  requirement  for  inclusion  in  P1003.4d  because  of  immaturity  of  existing  practice.  OSSWG 
should  pursue  this  requirement  in  the  Realtime  Distributed  Systems  Communication  working  group 
1003.21  at  such  time  in  the  future  as  existing  practice  can  be  identified.  The  1003.21  working  group  is 
currently  evaluating  how  such  information  might  be  applied  to  network  service  interfaces.  OSSWG  should 
re-evaluate  this  requirement  based  on  the  1003.21  findings,  both  as  applied  to  distributed  systems,  and  if 
applicable,  non-distributed  systems. 


3.13.6  Scheduling  Delay 

This  requirement  is  functionaiiy  identicaito  requirement  9.7  and  has  no  delta. 


3.13.7  Periodic  Scheduling 

The  requirement  for  Periodic  Scheduling  (13.7)  is  fully  met  by  1003.1  Signals,  alarm(),  and 
sleepO;  1003.4  Timers  and  High  Resolution  Sleep;  Pi 003.4a  Timed  Condition  Wait;  and  P1003.4b 
Sporadic  ^rver  and  Interrupt  Control.  The  POSIX  approach  of  specifying  performance  metrics  provides  a 
mechanism  for  the  jitter  to  be  determined  for  a  particular  implementation.  However,  performance  metrics 
are  currently  non-normative  text  in  1003.4  and  PI  003.4a;  therefore  OSSWG  should  support  future 
POSIX  projects  which  seek  to  standardize  performance  metrics. 


3.13.8  Multiple  Scheduling  Policies 

The  requirement  for  Multiple  Scheduling  Policies  (13.8)  is  covered  fully  by  1003.4,  Pi  003.4a, 
and  P1003.4b  Execution  Scheduling  interfaces. 


3.13.9  Selection  of  a  Scheduling  Policy 

The  requirement  for  Selection  of  a  Scheduling  Policy  (13.9)  is  covered  fully  by  1003.4,  PI  003.4a 
,  and  PI 003.4b  Execution  Scheduling  interfaces. 
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3.13.10  Modification  of  Scheduling  Parameters 

The  requirement  for  Modification  of  Scheduling  Parameters  (13.10)  is  covered  fully  by  1003.4, 
PI  003.4a.  and  PI  003.4b  Execution  Scheduling  interfaces. 


3.13.11  Precise  Scheduling  (Jitter  Management) 

The  requirement  for  Precise  Scheduling  (13.11)  is  fully  met  by  1003.4,  P1003.4a,  and  P1003.4b 
Execution  Scheduling,  Timers,  and  Interrupt  Control  interfaces.  The  POSIX  approach  of  specifying 
performance  metrics  provides  a  mechanism  for  the  latency  to  be  defined  for  a  particular  implementation. 
However,  performance  metrics  are  currently  non*normative  text  in  1003.4  and  Pi  003.4a;  therefore 
OSSWG  should  support  future  POSIX  projects  which  seek  to  standardize  perfonnance  metrics. 
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3.14  SYSTEM  INITIALIZATION  AND  REINITIALIZATION  INTERFACES 

This  service  class  is  partially  supported  by  1003.1, 1003.4,  P1003.7,  and  PI  003.8. 

All  three  requirements  from  this  service  class  are  classified  as  ’a”  (essential).  POSIX  generally 
supports  these  requirements  only  as  they  might  apply  to  a  shore-based  information  processing  system 
with  a  system  administrator  in  charge  of  overall  system  operation,  and  time-shared  users  in  charge  of 
initiating  and  terminating  independent  programs.  This  concept  must  be  extended  to  support  embedded 
real-time  systems  in  which  individual  programs  and  overall  system  operation  are  controlled  by  software, 
hardware,  or  other  nodes  on  a  distributed  processing  network,  rather  than  by  a  person.  Performance  also 
is  an  issue  largely  ignored  by  1003.7;  system  reinitialization  may  imply  an  operation  that  must  be 
completed  in  seconds  or  milliseconds,  rather  than  minutes. 


3.14.1  Image  Load 

This  unfulfilled  requirement  is  classified  as  "a*  (essential). 

The  Image  Load  requirement  (14.1)  can  be  supported  by  1003.1,  Process  Creation  and  Execute 
a  File,  but  not  in  the  traditional  sense  of  program  or  boot  load.  Pi 003.7,  when  complete,  would  fully 
support  this  function  in  the  Machine  Class  and  System  Class.  File  and  Directory  Services  of  1003.1  might 
also  be  required. 
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Raquirement:  The  OSIF  shaH  provide  the  capability  to  perform  inttial  and  reinitial  executable  image 
load  (including  data)  both  locally  and  remotely  to  and  for  each  and  aH  pfocessor(s)  throughout  a  system. 

Description  of  Delta:  The  POSIX  standard  is  based  on  the  traditionai  UNIX  paradigm  where  all 
processes  are  ultimately  children  of  the  root  process.  The  emerging  computing  environment  is  one  of 
muRipie  quasi-independent  processors  on  the  same  backplane,  or  network,  which  must  communicate  and 
interact  through  OS  services.  One  of  the  extensions  of  this  muHi-processor  environment  is  that  the  OS 
must  be  able  to  start  and  restart  each  of  the  computing  resources  available  to  R. 

In  the  1(K)3.1  standard,  the  ability  to  spawn  a  child  process  and  to  start  a  new  execution  are 
described.  These  senrices  will  partially  meet  the  requirements  of  Image  Loading.  The  issues  that  are  not 
addressed  by  these  sections  of  1003.1  are: 

1.  Loading  and  executing  on  a  remote  processor(s). 

2.  Loading  and  executing  on  another  local  processor(s). 

3.  Reloading  the  data  area  for  each  (re)initiaiization. 

Recommendation:  It  is  recommended  that  a  new  interface  be  created  either  by  the  1003.1  or 
1003.7  group.  The  interface  would  be  very  similar  to  the  various  exec()  interfaces  that  exist  in  1003.1. 
This  would  essentially  be  a  remote  execution  command,  sending  a  ’new  process  image  file,”  including 
both  executable  and  data  areas,  to  another  processor  to  be  executed. 

Note:  The  1003.7  standards  need  to  be  influenced  beyond  their  current  focus 
to  become  true  resources  manager  standards,  including  management  of 
both  remote  and  local  resources.  Hiis  change  would  help  meet  the  OCD 
requirements  for  not  only  section  20.14.1,  but  also  20.14.2  and  20.14.3 
(and  possibly  many  others). 


3.14.2  System  Initialization  and  Reinitialization 

This  unfuNilled  requirement  is  classified  as  ”a”  (essential). 

The  System  Initialization  and  Reinitialization  requirement  (14.2)  can  be  supported  by  the  entire 
sections  on  Process  Primitives  and  Process  Environment  of  1003.1.  1003.1  File  and  Directory  Services 
might  also  be  required. 

PI  003.7  fully  supports  this  function  in  the  Interoperability  Class,  Machine  Class,  System  Class, 
Network  Class.  Authentication  Class.  Authorization  Class,  Software  Class,  and  Backup  Class.  PI 003.7, 
when  complete,  could  become  the  NGCR  resources  management  standard  as  a  function  of  system 
administration.  WRh  some  influence  and  direction,  it  could  be  expanded,  either  as  a  profile  or  standard,  to 
support  the  necessary  NGCR  resources  management  functions.  AddRional  support  will  be  provided  by 
1003.4,  Clocks  and  Timers,  and  PI 003.8,  Process  Creation. 

Requirement:  The  OSIF  shall  support  the  capability  to  initialize  and  reinttialize  all  system 
resources. 

Description  of  DeRa:  tt  is  important  to  clarify  that  ’system  resources’  as  mentioned  in  the  OCO  are 
ALL  computing  resources  including,  but  not  limRed  to,  printers,  disk  drives,  external  and  shared  memory, 
co-processors,  tape  drives,  and  display  systems. 

1003.1  allows  for  process  creation  and  signal  generation/reception.  These  two  components 
oouU  be  made  to  help  in  performing  system  (re)initialization.  The  ability  to  start  processes  on  remote 
processors  (see  discussion  for  OCD  section  20.14.1)  could  cover  the  need  to  (re)initialize  some 
resources.  Other  resources  may  be  able  to  receive  POSIX  signals  that  would  cause  (re)initialization. 
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1003.1  aHows  for  ooflecting  system  information  and  parameters.  This  would  allow  the  OS  to  gain 
infonnatton  about  system  resources  so  that  it  would  imow  when  arxf  what  needed  to  be  (re)inttiaHzed. 

P1003.7  seems  to  have  the  outline  to  become  the  NGCR  resource  management  starxJard.  but  it 
needs  to  be  further  developed. 

Recommendation:  OSSWG  needs  to  influence  the  POSIX  standards  groups  (both  1003.1  and 
1003.7)  to  create  the  ability  for  the  operating  system  to  (re)initialize  the  system  resources.  This  capability 
really  doesnl  exist  in  the  POSIX  standards  but  is  an  absolute  requirement  for  OSSWG. 


3.14.3  Shutdown 

This  unfulfilled  requirement  is  classified  as  ‘‘a*  (essential). 

The  Shutdown  requirement  (14.3)  can  be  supported  by  1003.1,  Wait  for  Process  Termination 
and  Terminate  a  Process. 

Requirement:  The  OSIF  shall  provide  the  capability  to  perform  planned,  orderly  shutdown  at  the 
local  and  remote  levels  for  each  arvj  all  processor(s)  throughput  a  system. 

Description  of  Delta:  1003.1  outlines  how  POSIX  processes  can  stop,  but  offers  no  capability  for 
forcing  the  termination  of  one  process  from  another  non-reiated  process. 

Recommendation:  OSSWG  should  influence  the  POSIX  standards  to  inckjde  the  capability  to 
force  a  process  termination  on  remote  processors.  This  change  can  either  be  implemented  in  1003.1 ,  or 
ad^  to  PI 003.7  as  part  of  the  resources  management  standard. 
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3.15  TIME  SERVICES  INTERFACES 

In  general,  the  POSIX  standards  substantially  support  the  time  services. 

The  time  services  requirements  selection  of  a  primary  reference  clock  (15.4),  and  location  of  the 
primary  reference  clodt  (15.5)  are  not  specifically  supported  in  POSiX.  In  the  event  of  the  loss  of  the 
primary  reference  clock  the  OSIF  does  not  provide  a  means  to  iocate  a  new  primary  reference  dock  when 
needed. 

The  Ada  language  calendar  package.  Calendar,  and  the  1003.5  Ada  package,  POSIX_Calendar, 
are  equivalent  in  their  functionality.  They  have  the  same  provisions  for  getting  the  time  and  performing 
operations  against  that  time.  The  1003.5  package  POSIX_Caiendar  has  one  advantage  in  that  it  has  a 
procedure  to  override  the  system's  default  time  zone  through  the  TZ  environment  variable. 
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3.15.1  Read  Selected  Clock 

The  requirement  for  Read  Selected  Clock  (15.1)  for  timer  services,  and  for  precision  is  directly  and 
completely  met  by  1003.4  Clocks  and  Timers.  In  addition,  there  are  interfaces  in  1003.1,  1003.2, 
PI  003.4b.  and  potentially  PI 003.7  that  partially  meet  the  requirements  to  read  a  clock. 

System  Time  (paragraph  4.5.1. 1003.1  and  paragraph  4.4.1, 1003.5)  provides  access  to  a  time- 
of-day  dock,  with  precision  to  a  hundredth  of  a  second.  Process  Times  functions  (paragraph  4.5.2, 

1003.1  and  paragraph  4.2, 1003.5)  return  the  number  of  clock  ticks  since  the  beginnii^  of  a  particular 
process.  The  Clocks  and  Timers  interface  descrft>ed  in  1003.4  and  Pi  003.20  allows  muR^e  clocks  to  be 
defined.  Every  system  that  supports  this  interface  must  define  at  least  the  system  real-time  dock.  The 
interface  provides  for  potential  resolution  down  to  a  nanosecond. 

3.15.2  Sot  Selected  Clock 

The  requirement  for  Set  Selected  Clock  (15.2)  for  timer  senrices,  and  for  precision  is  directly  and 
completely  met  by  1003.4  Clocks  and  Timers  and  PI 003.4b  CPU  Time  Clocks  and  Device  Control,  in 
addition,  PI  003.7  can  address  setting  a  clock. 

System  Time  (paragraph  4.5.1,  1003.1  and  paragraph  4.4.1,  1003.5)  does  not  allow  for  setting 
the  time-of-day  clock.  All  clocks  defined  by  the  Clocks  and  Timers  interface  in  1003.4  and  Pi  003.20  may 
be  set  as  weB  as  read. 


3.15.3  Synchronization  of  Selected  Clocks 

The  requirements  for  Synchronizing  Selected  Clocks  (15.3)  for  timer  services  is  directly  arxj 
completely  met  by  1003.4  Clocks  and  Timers  and  P1003.4b  Device  Control. 

Synchronization  of  selected  clocks  is  supported,  through  the  combination  of  the  get  and  set 
functions  and  the  identification  of  the  clocks  throughout  the  system.  The  Device  Control  interface  in 
PI  003.4b  allows  getting  and  setting  clocks  located  on  an  external  device. 


3.15.4  Select  a  Primary  Reference  Clock 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 

The  Selection  of  a  Primary  Reference  Clock  is  not  specifically  supported  in  POSIX  since  the 
specific  wording  of  our  requirements  implies  the  ability  to  dynamically  reconfigure  the  system  wide  dock 
and  define  another  system  wkJe  dock. 

The  requirement  for  Selection  of  a  Primary  Reference  Clock  (15.4)  is  only  partially  met  by  1003.4 
and  PI  003.4b  Clocks  and  Timers.  Selection  of  a  primary  can  only  be  done  by  virtue  of  an  application's 
use  of  a  specific  clock  reference  which  must  be  inRially  defined  potentially  by  1003.7. 

There  is  no  means  to  set  or  change  the  defauK  in  a  dynamic  way. 

Reouirement:  The  OSIF  shall  support  the  ability  to  select  a  primary  reference  clock  for  the  system. 

Description  of  Delta:  POSIX  working  group  1003.21  has  identified  a  requirement  for  access  to 
global  time  in  their  requirements  document.  They  have  requested  a  new  PAR  on  time  management  to  be 
assigned  to  the  1003.21  working  group.  Pending  approval  of  this  PAR  and  initiation  of  a  draft  standard  on 
time  management,  POSIX  does  not  yet  address  this  issue. 

Recommendation:  The  OSSWG  should  support  the  1003.21  working  group's  time  management 
proposals  through  standardization  to  ensure  that  this  requirement  is  met. 
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3.15.5  Locate  the  Primary  Reference  Clock 

This  unfulfilled  requirement  is  classified  as  "d*  (re-evakiate). 

The  Location  of  the  Primary  Reference  Clock  is  not  sp^ifically  supported  in  POSIX  since  the 
specific  wording  of  our  requirements  implies  the  atulity  to  dynamically  reconfigure  the  system  wide  clock 
and  define  another  system  wide  clock. 

The  requirement  for  Location  of  the  Primary  Reference  Clock  (15.5)  is  limited  to  the  predefined 
system  wide  clock.  The  location  of  another  primary  reference  clock  in  the  event  of  a  failure  of  the 
predefined  system  wide  clock  is  not  covered  in  any  of  the  POSIX  documents.  This  failing,  as  well  as  the 
partial  cover^e  addressed  in  the  previous  paragraph,  is  attr&)utable  to  the  lack  of  real  attention  to  the 
needs  of  distrbuted  systems  and  the  demands  they  j^ace  on  time  sen/ices. 

Requirement:  The  OSIF  shall  support  the  ability  to  locate  the  primary  reference  dock  for  a  system. 

Description  of  Delta:  The  Distributed  Time  Services  requirements  in  the  1003.21  working  group 
requirements  document  refer  to  access  to  a  distributed  system  clock  without  reference  to  its  location. 
This  1003.21  working  group  requirement  should  preclude  the  need  for  OSSWQ  requirement  15.5. 

Recommendation:  The  OSSWG  should  support  the  1003.21  working  group  through 
standardization  of  it’s  proposed  draft  standard.  OSSWQ  should  consider  changing  this  requirement  to  be 
more  in  line  with  the  1003.21  requirement. 


3.15.6  Timer  Services 

The  Timer  Services  requirement  (15.6)  is  fulfilled  by  the  POSIX  standards  1003.1,  1003.4, 
PI  003.4a,  and  PI  003.4b.  The  Alarm,  Timer,  and  Interrupt  Control  interfaces  in  these  standards,  plus  the 
related  capabilities  to  await  signals  and  interrupts  satisfy  this  requirement. 


3.15.7  Precision  Clock 

Precision  Clock  (15.7)  is  fully  supported  by  the  1003.4  timespec  structure  for  Clocks  and  Timers, 
which  permits  resolutions  down  to  1  nanosecond. 
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3.16  ADA  LANGUAGE  SUPPORT 

The  POSIX  interface  reflects  fundamental  aspects  of  UNIX  and,  in  turn,  the  support  it  offers  to  Ada 
knpletnentations  must  be  seen  in  that  light.  UNIX  was  designed  and  built  to  support  a  multiple-user 
interactive  environment.  Its  whole  notion  and  implementation  of  process  reflects  the  need  to  supply 
resources  to  users  equitably,  while  protecting  them  from  accidental  interference  with  one  another.  In 
particular,  processes  are  the  only  objects  where  concurrency  is  applicable,  and  they  comprise  single 
threads  of  control  within  unique  address  spaces.  Further,  fundamental  aspects  of  the  design  of  the 
system  reflect  the  assumption  that  text  processing  and  I/O  would  be  important  aspects  of  the  processes 
supported,  and  that  the  processes  would  be  running  on  single-processor  computers.  (The  rrwre  general 
appiicabiniy  of  many  recent  implementations  has  had  to  deal  with  this  orientation  of  UNIX.) 

The  consequence  of  these  design  elements  of  UNIX  and  POSIX  is  that  the  general  POSIX 
definition,  1003.1,  does  not  offer  much  positive  support  for  the  implementation  of  Ada  systems.  In 
practice,  an  Ada  n/ntime  on  POSIX,  as  on  UNIX,  will  rrat  be  able  to  use  its  fundamental  services  (such  as 
process  management,  synchronization,  and  scheduling)  to  provide  Ada  semantics  directly. 

The  fundamental  reason  for  this  lack  of  support  is  that  POSIX  processes  are  unsuitable  as  a 
mapping  for  Ada  tasks.  Processes  do  not  share  memory,  and  tasks  do.  Processes  can  continue 
executing  even  when  their  parents  have  terminated,  while  this  is  not  possible  for  Ada  tasks.  Processes 
inherit  their  parents'  attributes  in  ways  that  Ada  tasks  do  not.  Switching  contexts  between  processes  has 
more  overhead  than  would  be  desirable  for  tasks. 

This  does  not  mean  that  Ada  cannot  be  implemented  in  a  POSIX  system.  It  simply  means  that  the 
Ada  runtime  will  need  to  do  most  of  its  own  work  to  implement  Ada  semantics.  Also,  there  are  some 
instances  in  which  POSIX,  like  UNIX,  will  get  in  the  way;  such  as  the  fact  that  makir^  a  request  for  I/O 
blocks  an  entire  process  (read  Ada  program).  This  is  understandable  in  a  multi-user  interactive 
environment,  but  is  unsuitable  in  many  Ada  applications. 

The  real-time  extensions  (1003.4),  however,  and  particularly  the  threads  extensions  (Pl003.4a), 
are  more  helpful.  First  of  all,  synchronization  primitives  (semaphores,  mutexes,  and  condition  variables) 
are  made  available.  Second,  threads  appear  to  provide  a  suitable  mapping  to  Ada  tasks,  such  that  it  would 
be  feasbie  to  assume  that  a  POSIX  implementation  which  inch/ded  the  real-time  and  threads  options 
could  provide  task  management  and  scheduling  for  an  Ada  runtime  environment.  Other  services  could  be 
used  directly  to  implement  Ada  semantics  as  well. 

In  general,  in  some  instances,  Ada  semantics  will  be  implementable  by  inserting  calls  to  POSIX 
real-time  and  thread  senrices  directly  into  the  compiled  code.  On  the  other  hand,  in  most  instances,  the 
Ada  runtime  library  will  need  to  carry  out  extra-POSIX  activities;  sometimes  with  the  assistance  of  calls  to 
POSIX  services,  and  occasionally  completely  on  its  own.  The  threads  extensions  (PI 003.4a)  document 
outlines  how  an  Ada  system  might  map  tasks  on  the  threads  primitives. 

In  this  section  it  is  assumed  that  the  Ada  binding  to  POSIX  (1003.5)  is  a  reflection  of  1003.1, 
rather  than  the  provision  of  additional  support  for  Ada.  1003.5  provides  for  Ada  I/O  support  in  addition  to 
the  POSIX  I/O  and  adds  services  to  relate  the  two  types  of  I/O. 

In  general,  the  POSIX  standards  support  senrice  class  16,  Ada  language  support  interface,  in  a 
substantially  complete  way  for  the  POSIX  (Pi  003.4a)  thread  model  and  in  a  rudimentary  way  for  the  POSIX 
process  model  (1003.1). 

The  requirements  for  the  Ada  task  model  are  met  in  a  fairly  direct  way  by  the  POSIX  thread  model. 
The  support  of  tasks  in  isolation  (i.e.,  create  (16.1),  terminate  (16.5),  etc.)  is  quite  direct.  The  support  of 
Ada  rendezvous  and  selective  waiting  is  complete,  but  it  requires  extensive,  specialized  composition  of 
POSIX  services. 

A  number  of  the  OSSWQ  requirements  for  the  support  of  Ada  are  requirements  for  services  to  be 
provided  by  the  run-time  system.  These  requirements  include  access  to  task  characteristics  (16.9), 
access  to  a  precise  real-time  clock  (16.1 1),  access  to  the  time-of-day  clock  (16.12),  dynamic  task  priorities 
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(16.13),  memory  management  (16.15),  and  exception  raising  (16.19).  The  POSIX  thread  model  supports 
these  run-time  system  requirements  with  a  few  exceptions. 

The  unfulfilled  requirements  in  this  section  ve  duplications  of  requirements  in  previous  sections. 
They  are  requiremerAs  that  have  sp^ial  relevance  for  Ada  language  applications,  but  if  they  are  fulfilled  by 
the  OSIF  in  general,  they  will  be  fulfilled  also  for  Ada  applications.  It  does  not  seem  wise  to  duplicate  the 
exposition  of  the  issues,  since  It  would  incur  the  dangers  of  duplicate  maintenance.  These  sections  will 
therefore  refer  to  the  sections  that  define  the  issues  and  recommend  actions. 

Some  general  recommendations  are  appropriate,  however,  to  ensure  that  the  solutions  derived 
for  the  deltas  are  appropriate  for  Ada  applications; 

1.  The  OSSWG  should  remain  active  in  the  1003.5  (Ada  Bindings)  group  to  ensure  that  the  Ada 
bindings  to  POSIX  interfaces  are  adequate  to  fulfill  the  requirements  of  NGCR  Ada  applications. 

2.  The  discussions  of  the  specified  deltas  in  previous  sections  should  also  make  reference  to  the 
Ada-specific  section  to  ensure  that  the  deita  is  resolved.  Even  in  the  unlikely  event  that  it  were  to  be 
dedd^  that  there  is  no  general  need  for  the  functions,  there  is  still  a  requirement  in  an  Ada  context.  This 
judgment  should  not  be  lost. 

3.  The  OSSWG  should  follow  the  progress  of  Ada9X,  since  there  is  some  indication  that  language 
changes  will  be  made  that  will  have  impact  on  requirements  defined  in  this  section. 


3.16.1  Create  Task  (Ada) 

The  requirement  for  Create  Task  (16.1)  is  met  by  PI  003.4a.  Refer  to  the  Rhreads  disdjssion  in 

3.9.1. 


3.16.2  Abort  Task  (Ada) 

This  unfulfilled  requirement  is  classified  as  "a”  (essential). 

This  requirement  is  unfulfilled  for  the  same  reason  that  requirement  9.2  is  unfulfilled;  that  is,  there 
is  no  interface  provided  in  PI 003.4a  to  unconditionally  terminate  a  thread.  Refer  to  section  3.9.2  for 
recommendations. 


3.16.3  Suspend  Task  (Ada) 

The  requirement  for  Suspend  Task  (16.3)  is  met  by  1003.4  and  Pi 003.4a.  Refer  to  the  Rhreads 
discussion  in  3.9.5. 


3.16.4  Resume  Task  (Ada) 

The  requirement  Resume  Task  (16.4)  is  met  by  1003.4  and  PI  003.4a.  Refer  to  the  Rhreads 
discussion  in  3.9.6. 


3.16.5  Terminate  Task  (Ada) 

The  requirement  Terminate  Task  (16.5)  is  addressed  by  Pl003.4a  Thread  Cancellation.  Ada  task 
termination  semantics  imply  cooperation  form  the  terminating  task;  thus  thread  cancellation  provides  a 
suitable  interface  to  meet  this  requirement  in  spite  of  its  inability  to  unconditionally  terminate  an 
uncooperative  task. 
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3.16.6  Restart  Task  (Ada) 

This  unfulfilled  requirement  is  classified  as  "d*  (re-evaluate). 

The  proposed  Ada  extension  to  support  “Restart  Task*  (16.6)  is  not  supported  by  either  the 
POSIX  process  or  thread  model.  This  requirement  is  perhaps  the  most  controversial  of  the  proposed  Ada 
extensions. 

Restart  Task  (Ada)  (16.6)  is  required  for  OSSWG  if  seen  independently  from  its  connection  to 
support  for  Ada:  as  such  it  is  dealt  with  in  requirement  9.13  (save/restart  process).  On  the  other  hand,  the 
requirement  does  not  relate  to  the  current  definition  of  the  Ada  language  and  therefore  should  be 
reevaluated  as  to  whether  it  should  be  duplicated  in  this  section.  Some  people  in  the  Ada  community 
have  suggested  that  the  language  should  be  modified  to  allow  more  direct  access  to  these  functions,  and 
it  is  possible  these  functions  will  be  included  in  the  next  revision,  now  called  Ada-9X.  Thus,  this 
requirement  is  classified  as  ‘d*  (re-evaluate). 

Requirement:  The  OSIF  shall  support  the  capability  to  restart  the  execution  of  an  Ada  task  at  a 
point  immediately  following  its  elaboration  code. 

Description  of  Delta:  This  requirement  reflects  a  need  to  provide  extensions  to  the  current  Ada 
tankage  standard.  OSSWG  should  give  careful  study  to  the  appropriateness  of  the  requirement,  monitor 
the  progress  of  language  modification  efforts,  and  propose  further  additions  to  the  POSIX  standard,  either 
as  changes  to  PI 003.4a  or  inclusion  in  PI 003.4b. 

Recommendation:  See  section  3.9.13.  OSSWG  should  re-evaluate  this  requirement  this 
requirement  based  on  Ada-9X  capabilities. 


3.16.7  Task  Entry  Calls  (Ada) 

Some  of  the  claims  found  in  Pl003.4a  regarding  support  of  Task  Entry  Calls  (16.7)  cannot  be  fully 
accepted  without  further  proof  through  implementation  and  validation.  The  1003.5  working  group  has 
submitted  objections  to  .4a  which,  if  resolved,  will  allow  Ada  tasks  to  be  mapped  to  .4a  threads.  If  not 
resolved,  and  without  mapping  Ada  tasks  to  threads.  Task  Entry  Calls  can  still  be  achieved  via  other  POSIX 
interfaces,  but  with  reduced  performance. 


3.16.8  Task  Call  Accepting/Selecting 

Some  of  the  claims  found  in  PI  003.4a  regarding  support  of  accepts  (16.8)  cannot  be  fully 
accepted  without  further  proof  through  implementation  and  validation.  The  1003.5  working  group  has 
submitted  objections  to  .4a  which,  if  resolved,  will  allow  Ada  tasks  to  be  mapped  to  .4a  threads.  If  not 
resolved,  and  without  mapping  Ada  tasks  to  threads.  Task  Call  Accepting/Selecting  can  still  be  achieved 
via  other  POSIX  interfaces,  but  with  reduced  performance. 


3.16.9  Access  Task  Characteristics  (Ada) 

The  requirement  to  Access  Task  Characteristics  (16.9)  is  supported  by  Clock  and  Timer  Functions 
of  1003.4,  Thread  Management  and  Thread  Cancellation  of  PI  003.4a,  and  also  Thread  Scheduling 
Functions  and  CPU-Time  Clock  of  PI 003.4b. 
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3.16.10  Monitor  Task's  Execution  Status  (Ada) 

This  unfuHiiled  requirement  is  classified  as  ‘a*  (essential). 

Monitor  Task’s  Execution  Status  (Ada)  (16.10)  is  required  by  OSSWG  and  is  dealt  with 
kidependently  in  requirements  9.11  (Examine  Process  Status)  and  13.3  (Cumulative  Execution  Time  of  a 
Process). 

This  requirement  is  important  to  the  spirK  of  the  Ada  standard  and  to  real-time  applications. 
OSSWG  should  propose  further  additions  to  the  POSIX  standard,  either  as  changes  to  Pi  003.4a  or 
inclusion  in  PI  003.7. 

Reouirement:  The  OSIF  shall  support  the  ability  to  monitor  a  task's  execution  status,  in  particular, 
the  amount  of  accumulated  CPU  time  that  has  been  used  by  the  task. 

Description  of  Delta:  The  requirement  for  Monitor  Task's  Execution  Status  (16.10)  is  not  met  by 
1003.1,  1003.4,  or  PI  003.4a.  Since  Ada  tasks  must  be  mapped  onto  POSIX  threads  the  standard 
process  primitives  are  not  available  to  support  this  requirement.  1003.2  has  not  been  extended  to 
address  thread  status.  Pi  003.4b  does  allow  access  to  the  CPU  time  used  by  a  thread. 

Recommendation:  See  section  3.9.1 1 . 


3.16.11  Access  to  a  Precise  Real-Time  Clock  (Ada) 

The  requirement  to  Access  a  Precise  Real-Time  Clock  (16.11)  is  covered  in  sections  3.15.1, 
3.15.2,  and  3.15.7.  There  is  no  additional  requirement  peculiar  to  Ada. 


3.16.12  Access  to  a  TOD  Clock  (Ada) 

The  requirement  to  Access  a  Time  of  Day  Clock  (16.12)  is  covered  in  sections  3.15.1 , 3.15.2,  and 
3.15.7.  There  is  no  additional  requirement  peculiar  to  Ada. 

3.16.13  Dynamic  Task  Priorities  (Ada) 

The  Dynamic  Task  Priorities  requirement  (16.13)  is  provided  by  both  PI  003.4a  and  PI  003.4b, 
with  interfaces  to  get  and  set  thread  scheduling  parameters. 


3.16.14  Scheduling  Policy  Selection  (Ada) 

Schetkiling  Policy  Selection  (16.14)  is  also  required  by  OSSWG  and  is  dealt  with  independently 
in  requirement  13.9  (Selection  of  a  Scheduling  Policy).  While  not  directly  visible  to  Ada  applications,  this 
interface  may  be  critical  to  the  implementation  of  an  Ada  run-time. 

This  requirement  reflects  a  need  to  provide  extensions  to  the  current  Ada  language  standard. 
OSSWG  should  give  careful  study  to  the  appropriateness  of  the  requirement  and  monitor  the  progress  of 
language  modification  efforts. 

The  Scheduling  Policy  Selection  (16.14)  requirement  is  fully  supported  by  1003.4  and  P1003.4a 
(1003.1  provides  no  support  for  scheduling  policy  selection).  Reference  PI 003.4a,  Thread  Creation 
Scheduling  Attributes,”  "Thread  Scheduling;"  1003.4,  "Execution  Scheduling;",  and  PI  003.4b, 
"Process  and  Thread  Scheduling  Functions." 
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A  number  of  the  OSSWG  requirements  for  Ada  language  support  are  actually  requirements  for 
Ada  extensions  that  may  or  may  not  become  a  part  of  the  language  standard  in  the  future.  In  the  case  of 
sche^ling  policy  selection  (16.14),  the  1003.4,  Pl003.4a  ,  and  Pl003.4b  interfaces  provide  extensive 
support. 

Reouirement:  The  OSIF  shall  support  the  capability  to  get  and  set  the  policy  that  is  to  be  used  to 
schedule  Ada  tasks. 

Recommendation:  There  is  no  longer  an  OSSWG  delta  per-se,  but  rather  only  an  Ada  delta.  It  is 
recommended  that  OSSWG  address  this  issue  as  a  whole. 


3.16.15  Memory  Allocation  and  Deallocation  (Ada) 

This  unfulfilled  requirement  is  classified  as  "a"  (essential). 

Memory  Allocation  and  Deallocation  (Ada)  (16.15)  is  required  by  OSSWG  and  is  dealt  with 
independently  in  requirement  12.3  (Dynamic  Memory  Allocation  and  Deallocation).  It  is  particularly 
important  to  the  implementation  of  Ada  systems. 

This  requirement  is  unfulfilled  for  the  same  reason  that  requirement  12.3  is  unfulfilled;  that  is, 
there  are  no  sufficiently  flexible  interfaces  provided  in  POSIX  for  dynamic  memory  allocation  and 
deallocation,  but  the  Typed  Memory  interfaces  in  P1003.4d  will  satisfy  this  requirement  once  a  draft  is 
produced.  There  is  no  additional  requirement  peculiar  to  Ada.  Refer  to  section  3.12.3  for 
recommendations. 


3.16.16  Interrupt  Binding  (Ada) 

This  requirement  is  directly  met  by  PI  003.4b  Interrupt  Control. 


3.16.17  Enable/Disable  Interrupts  (Ada) 

Enable/Disable  Interrupts  (Ada)  (16.17)  is  required  for  OSSWG  if  seen  independently  from  its 
connection  to  support  for  Ada;  as  such  it  is  dealt  with  in  requirement  5.5  (Enable/Disable  Interrupts). 
There  is  no  longer  a  delta  for  requirement  5.5  because  PI 003.4b  includes  interfaces  which  provide 
mutual  exclusion  between  an  application  and  its  interrupt  handler.  On  the  other  hand,  the  requirement 
does  not  relate  to  the  current  definition  of  the  Ada  language  and  therefore  should  be  reevaluated  as  to 
whether  it  should  be  duplicated  in  this  section.  Some  people  in  the  Ada  community  have  suggested  that 
the  language  should  be  modified  to  allow  more  direct  access  to  these  functions,  and  it  is  possible  these 
functions  will  be  included  in  the  next  revision,  now  called  Ada-9X.  Thus,  this  requirement  is  classified  as 
"d"  (reevaluate). 

This  requirement  reflects  a  need  to  provide  extensions  to  the  current  Ada  language  standard. 
OSSWG  should  give  careful  study  to  the  appropriateness  of  the  requirement  and  monitor  the  progress  of 
language  modification  efforts. 

A  number  of  the  OSSWG  requirements  for  Ada  language  support  are  actually  requirements  for 
Ada  extensions  that  may  or  may  not  become  a  part  of  the  language  standard  in  the  future.  In  the  support 
of  Enable/Disable  Intermpts  (16.17),  as  described  in  the  OSSWG  requirements,  a  marginally  satisfactory 
masking  capability  is  provided  in  1003.1,  1003.4,  and  PI  003.4a  as  related  to  signals;  but  PI  003.4b 
Interrupt  Control  provides  a  much  more  generic  capability. 

Reouirement:  The  OSIF  shall  support  the  capability  to  enable  and  disable  interrupts. 
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Rftcommendation:  OSSWG  should  re-evaluate  this  requirement  based  on  Ada-9X  capabilities. 
There  is  no  OSSWG  deRa  per-se,  but  rather  only  an  Ada  delta. 

3.16.18  Mask/Unmask  Interrupts  (Ada) 

This  unfulfilled  requiremerrt  is  classified  as  ‘‘c*  (may  be  deferred). 

Mask/Unmask  interrupts  (Ada)  (16.18)  is  required  for  OSSWG  if  seen  independently  from  its 
connection  to  support  for  Ada;  as  such  it  is  dealt  with  in  requirement  5.6  (Mask/Unmask  Interrupts).  On 
the  other  hand,  the  requirement  does  not  relate  to  the  current  definition  of  the  Ada  language  and 
therefore  should  be  reevaluated  as  to  whether  it  should  be  duplicated  in  this  section.  Some  people  in  the 
Ada  community  have  suggested  that  the  language  should  be  modified  to  allow  more  direct  access  to 
these  functions,  and  it  is  possible  these  functions  will  be  included  in  the  next  revision,  now  called  Ada-9X. 
Thus  this  requirement  is  classified  as  "(T  (reevaluate). 

This  requirement  reflects  a  need  to  provide  extensions  to  the  current  Ada  language  standard. 
OSSWG  should  give  careful  study  to  the  appropriateness  of  the  requirement  and  monitor  the  progress  of 
ianguage  modification  efforts. 

A  number  of  the  OSSWG  requirements  for  Ada  language  support  are  actually  requirements  for 
Ada  extensions  that  may  or  may  rrot  become  a  part  of  the  language  standard  in  the  future.  In  the  support 
of  Mask/Unmask  Interrupts  (16-18).  as  described  in  the  OSSWG  requirements,  only  a  marginally 
satisfactory  masking  capability  is  provided  in  1003.1, 1003.4,  and  PI  003.4a  as  related  to  signals.  The 
PI 003.4b  Device  Control  interface  may  be  interpreted  as  a  standard  way  to  request  a  device  to  mask  or 
unmask  its  interrupts. 

Requirement:  The  OSIF  shall  support  the  capability  to  mask  and  unmask  device  interrupts. 
Recommendation:  Same  as  in  section  3.5.6.  There  is  no  additionai  requirement  peculiar  to  Ada. 


3.16.19  Raise  Exception  (Ada) 

Support  for  the  Raise  Exceptions  requirement  (16.19)  is  believed  to  be  provided  by  a 
combination  of  services  for  signals  within  1003.1,  1003.4  and  P1003.4a,  but  this  support  has  not  yet 
been  proven. 

3.16.20  i/0  Support  (Ada) 

The  requirement  for  Ada  Input/Output  Support  (16.20)  is  partially  covered  by  1003.1,  1003.4, 
PI  003.4a,  1003.5,  and  PI  003.20.  1003.1, 1003.4,  and  PI  003.4a  define  the  POSIX  file  support  and  I/O 
primitives.  1003.5  and  PI 003.20  provide  the  Ada  binding  to  those  POSIX  features,  as  well  as  services  to 
convert  between  the  two  versions.  Support  for  Ada  Low_LevelJO  is  provided  by  the  PI  003.4b  Device 
Control  interface. 
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Requirements  Coverage  Summary 


Requirement 

Covered 

POSIX  Delta 

Unfulfilled 

Requirements 

Rating 

16.1 

Yes 

None  (1.3)* 

- 

16.2 

Partiallv 

Insertion  (1.3) 

a 

16.3 

Yes 

None  (1,3) 

- 

16.4 

Yes 

None  (1,3) 

- 

16.5 

Yes 

None  (1.3) 

- 

16.6 

No 

Insertion  (2) 

d 

16.7 

Yes 

None  (1.3) 

- 

16.8 

Yes 

None  (1.3) 

- 

16.9 

Yes 

- 

16.10 

No 

Insertion 

a 

16.11 

Yes 

None 

- 

16.12 

Yes 

None 

- 

16.13 

Yes 

None 

- 

16.14 

Yes 

None  (2) 

- 

16.15 

No 

Modification 

a 

16.16 

Yes 

None 

- 

16.17 

Yes 

None(2) 

- 

16.18 

No 

Modification  (2) 

c 

16.19 

Yes 

None  (1.3) 

- 

16.20 

Yes 

None 

- 

*1  Requires  a  solid  commitment  to  1003.4  and  PI  003.4a  by  the  POSIX  standards  effort. 


2  Requires  coordination  between  the  Ada  language  standard  and  the  POSIX  standard. 

3  Awaiting  proof  of  adequacy  of  POSIX  interfaces. 
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4.  BIG  6  DISCUSSION 


This  section  analyzes  of  the  extent  to  which  the  POSIX  standards  meet  what  the  NGCR  OSSWG 
has  termed  the  "Big  Six."  This  refers  to  six  technology  areas  that  the  Navy's  NGCR  Program  Office  has 
stated  as  beirn]  of  prime  importance  to  future  Navy  systems.  These  areas  as  related  to  computer  systems 
are  Distribution,  Real-Time,  Fault-Tolerance,  Security.  Heterogeneity,  and  Ada. 

4.1  DISTRIBUTED  SYSTEMS 

It  was  always  a  primary  goal  of  NGCR  in  general,  and  the  NGCR  OS  in  particular,  to  support  the 
wide  variety  of  distributed  architectures  found  in  Navy  systems.  Such  systems  include  anywhere  from  two 
to  hundreds  of  homogeneous  and/or  heterogeneous  processing  and  I/O  nodes  communicating  either 
point-to-point  or  via  a  multi-level  bus  or  network  interconnection.  Ideally,  the  operating  system  interface 
should  provide  distributed  services  in  a  portable  manner,  masking  the  actual  method  of  interconnection 
and  its  associated  protocols. 

Operating  system  services  related  to  distributed  processing  can  be  broadly  classified  as  either 
explicit  or  implicit  distribution.  Explicit  distribution  irnplies  that  the  application  directs  a  request  to  a  specific 
logically  identified  node;  an  example  of  explicit  distribution  is  sendirig  a  message  to  a  specified  node  or  I/O 
subsystem  and  awaiting  a  reply.  Implicit  distribution,  conversely,  implies  that  the  application  is  unaware  of 
where  in  the  distributed  system  a  requested  service  is  provided;  examples  of  implicit  distribution  include 
file  servers,  name  servers,  and  the  like. 


4.1.1  Distribution  in  UNIX 

Traditionally,  UNIX  systems  have  been  primarily  implemented  on  single  node,  uniprocessor 
systems.  When  the  need  for  operation  in  a  networked  environment  became  obvious  (stimulated  by  the 
ARPANET  research  in  the  late  1970s  and  early  1980s),  explicit  distributed  services  first  began  to  af^ear 
as  shell  and  utility  add-ons  to  the  basic  UNIX  systems;  such  facilities  as  electronic  mail  and  file  transfer 
services  were  built  on  OS  and  vendor-specific  implementations  of  Defense  Advanced  Research  Projects 
Administration's  (DARPA)  TCP/IP  networking  protocol.  Researchers  at  the  University  of  California 
Berkeley  developed  a  portable  API  suitable  for  interprocess  communication  within  a  single  node  or  across 
nodes  via  networking  protocols;  this  interface,  called  Sockets,  became  a  de-facto  standard  API  for 
networking  applications,  thereby  allowing  portable  versions  of  these  explicit  services  to  be  built  as  utility 
applications.  AT&T  developed  a  similar  interface,  XTI,  for  its  System  V  variant  of  UNIX. 

In  recent  years,  additional  utility  level  explicit  distributed  services  have  become  standard  in  most 
UNiX  systems.  These  include  remote  shell,  remote  login,  remote  talk,  and  finger  services,  all  implemented 
using  a  client-server  model  at  the  UNIX  application  level,  and  utilizing  the  Sockets  or  XTI  API  to  send  and 
receive  service-specific  messages  via  service-specific  sockets  across  distributed  nodes.  Even  more 
recently,  implicit  distributed  services  have  been  integrated  into  some  UNIX  systems,  such  as  network  file 
system  and  domain  name  server  capabilities.  These  achieve  a  level  of  application  transparency  by 
embedding  the  remote  node  identification  in  configurable  operating  system  tables  that  are  maintained  by 
a  system  administrator  but  are  otherwise  of  no  concern  to  portable  applications. 

Very  recent  developments  in  transparent  distributed  database  and  information  retrieval  include 
the  WAIS  (Wide  Area  Information  Server)  and  Internet  Gopher  systems  which  both  provide  a  seamless 
local  user  interface  to  widely  distn'buted  information. 


4.1.2  Distribution  in  POSIX 

The  POSIX  working  groups  seek  to  standardize  current  practice  in  the  UNIX  community.  The 
current  working  groups  therefore  focus  on  a  protocol  independent  interface  (PI 003.1 2),  transparent  file 
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access  (P1003.8),  directoiy  services  (1224.2),  object  management  (1224),  X.400  message  handling 
(1224.1),  and  common  OSI  API  &  FTAM  API  (Pi 238)  for  distributed  systems. 

The  protocol  independent  interface  is  currently  based  on  the  Berkeley  Sockets  and  XTI  de-facto 
standards.  A  new  PAR  (Real  Time  Distributed  Systems  Communicaiion  -  1003.21)  has  proposed 
extending  these  capabilities  for  realtime  systems.  Likewise,  the  other  APIs  are  based  on  de-facto  industry 
standards.  While  1224  and  P1238  are  not  strictly  part  of  POSIX  (1003),  they  are  part  of  the  IEEE  PASO 
(Portable  Applications  Standards  Committee),  and  meet,  distribute  documents,  and  generally  coordinate 
wHh  POSIX. 


4.1.3  Distribution  in  NGCR  OS 

All  NGCR  OS  distribution  requirements  are  not  called  out  explicitly  as  OSSWG  requirements. 
While  the  network  and  communications  interfaces  service  class  specifies  the  lowest  level  requirements  for 
internode  communication  over  LAN,  bus,  and  point-to-point  hardware  interconnects,  distribution  is 
implicitly  required  by  a  number  of  APIs  in  other  service  classes.  Each  and  every  OSSWG  requirement 
must  be  interpreted  in  the  following  manner:  If  this  requirement  makes  sense  in  a  distributed  context,  then 
the  NGCR  OS  must  support  it  in  that  distributed  context. 

For  example.  Navy  embedded  systems  traditidnally  support  some  form  of  interprocess 
communication  among  processes  at  separate  nodes;  thus,  OSSWG  requirement  9.8  (interprocess 
comiTXjnication)  requires  distribution  support.  In  this  case,  the  OSSWG  requirement  is  general  enough  to 
cover  both  explicit  distribution  (i.e.,  the  application  sets  up  the  logical  pathway  between  the  processes) 
and  implicit  distribution  (i.e.,  the  application  interface  is  no  different  whether  the  communication  is 
intemode  or  intranode). 

As  a  counterexample,  the  OSSWG  requirement  for  mutual  exclusion  (13.2)  is  typically  not 
implemented  across  nodes  in  Navy  embedded  systems,  at  least  not  at  the  operating  system  level.  The 
reason  for  this  is  that  mutual  exclusion  primitives  are  intended  to  be  a  high  performance,  low  contention 
method  for  guarding  shared  resources  against  inappropriate  simultaneous  access;  this  model  becomes 
virtually  useless  over  high  latency  intemode  communication  paths.  Resources  sharable  across  multiple 
loosely  coupled  nodes  occur  quite  infrequently  and  are  typically  guarded  with  other  mechanisms  such  as 
monitors  (server  processes). 


4.1.4  NGCR/POSIX  Distribution  Delta 

During  the  OSSWG  evaluations  that  led  to  the  selection  of  POSIX  as  the  baseline  for  the  NGCR 
MIL-STD  OSIF,  evaluators  were  constantly  aware  that  each  OSSWG  requirement  might  have  different 
implications  in  a  loosely  or  tightly  coupled  distributed  system  than  in  a  simple  uniprocessor  system. 
Although  there  is  no  OSSWG  service  class  dealing  specifically  with  distribution,  service  classes  2, 4, 8, 12, 
and  14  contain  requirements  that  deal  specifically  with  the  explicit  nature  of  distributed  systems.  Most 
other  service  classes  contain  one  or  more  requirements  for  which  some  NGCR  distributed  systems  will 
undoubtedly  need  transparent  (implicit)  distribution.  The  OSSWG  has  not  reached  a  consensus  on 
exactly  which  POSIX  interfaces  should  be  transparently  distributed.  However,  since  POSIX  is  currently 
providing  very  little  transparent  distribution  of  services,  the  delta  is  likely  to  widen  when  such  transparent 
service  interlaces  are  identified. 


4.2  REAL-TIME  SYSTEMS 

The  primary  application  of  the  NGCR  OS  is  in  support  of  Navy  air,  surface,  subsurface,  and  shore- 
based  mission  computer  systems.  The  secondary  application  is  in  all  other  Navy  computer  systems, 
including  software  development,  laboratory,  and  non-military  functions.  Virtually  all  of  the  primary 
applications  and  some  of  the  secondary  aii^lications  have  real-time  constraints  ranging  from  "soft”  to 
"hard"  real  time.  UNIX  operating  systems  have  traditionally  offered  very  poor  support  for  users  with  real- 
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time  requirements.  Faced  with  this  dismai  r^jutation,  various  UNIX  vendors  have  offered  a  variety  of 
nonstandard,  nonportable  real-time  extensions  to  the  UNIX  kernel. 


4.2.1  Real  Time  in  POSIX 

POSIX  working  group  1003.4  is  attenpting  to  standardize  the  various  real-time  extensions.  Prior 
to  participation  in  1003.4  by  the  NGCR  OSSWG  and  the  VITA  (ORKID  standard)  members,  the  working 
group  activities  were  focus^  primarily  on  "soft"  real-time  issues.  Now,  these  participants  have  joined  wKh 
the  real-time  system  vendors  in  ensuring  that  'hard*  real-time  is  given  its  (kje.  It  is  POSIX  1003.4  policy 
that  Ms  work  will  also  address  usability  of  the  extensions  for  other  than  real-time  systems  whenever 
possible.  The  following  enhancement  categories  are  in  progress; 

1.  Semaphores  provide  a  facility  for  syr)chronization  among  multiple  processes  contending  for 
access  to  a  shared  resource.  The  traditional  UNIX  approach  (lock  files)  is  too  time  consuming  arxl  disk 
intensive  to  be  useful  in  high  performance  real-time  systems,  especially  when  expected  contention  for 
the  resource  is  very  low,  as  is  typically  the  case. 

2.  Process  memory  locking  provides  an  application  API  allowing  the  user  to  designate  certain 
program  and/or  data  memory  to  be  excluded  from  the  rtormal  UNIX  virtual  memory  management 
paging/swappirtg  algorithms.  This  allows  critical  memory  reg'ons  to  be  guaranteed  prompt  accessibility 
and  minimizes  nondeterministic  behavior  due  to  mass  storage  latency. 

3.  Shared  memory  interfaces  enable  a  high  bandwidth  and  high  performance  form  of  interprocess 
communication  when  the  hardware  supports  this,  the  real-time  constraints  require  this,  and  the  protection 
afforded  by  more  structured  forms  of  IPC  can  be  sacrificed. 

4.  Priority  scheduling  interfaces  permit  real-time  applications  to  override  the  de-facto  time¬ 
sharing”  UNIX  style  process  scheduling  policy  with  various  priority  based  scheduling  policies  more 
appropriate  to  real-time  muMMasking.  Only  by  doing  this  can  hard  real-time  deadlines  be  guaranteed. 

5.  Realtime  Signals  extends  the  classic  UNIX  signal  concept  by  allowing  arbitrary  user  defined 
signals  to  be  attached  to  user  initiated  actions  and  external  events,  and  subsequently  notifying  the  user 
process  (synchronously  or  asynchronously)  when  the  event  is  triggered. 

6.  Clocks  and  timers  provide  APIs  to  various  resoli/j'on  clocks  and  interval  timers  that  provide 
better  granularity  and  more  flexibility  than  the  traditional  UNIX  1/Hz-second  clock  (time)  and  1 -second 
interval  timer  (alarm,  sleep).  Real-time  systems  usually  have  tight  timing  tolerances  that  are  best  met  by 
millisecond  or  better-resolution  low-jitter  clocks  and  timers. 

7.  IPC  Message  passing  addresses  the  need  for  a  form  of  interprocess  communication  interface 
that  is  not  inexorably  tied  to  any  specific  implementation  but  that  supports  loosely  coupled  LAN-based 
communications  typical  among  component  subsystems  of  a  large  combat  systems,  as  well  as  high 
performance  shar^  memory  based  communications  between  cooperating  processes  in  a  uniprocessor 
or  multiprocessor.  The  traditional  UNIX  IPC  mechanisms  (pipes,  signals,  and  files)  are  often  too  restrictive 
or  heav^eight  for  use  in  real-time  systems. 

8.  Synchronized  input  and  output  provides  interfaces  whereby  an  application  can  guarantee  that 
a  set  of  data  recorded  in  mass  storage  is  current  and  self  consistent.  Traditional  UNIX  I/O  assumes  that  the 
"OS  knows  best”  but  fails  to  address  the  need  for  embedded  real-time  systems  to  more  closely  control  the 
reading  and  writing  of  data  that  might  be  needed  for  recovery  purposes  or  might  be  written  and  read  by 
different  components  of  the  system. 

9.  Asynchronous  input  and  output  provides  aHemative  I/O  interfaces  that  ali  ngle  process  to 
initiate  I/O  to  one  or  several  devices  simultaneously  and  continue  processing  w  .  awaiting  I/O  to 
complete.  The  traditional  UNIX  approach  to  this  is  to  create  separate  processes  to  perform  each  I/O 
operation  as  well  as  queuing  and  notification  functions.  While  this  approach  can  actually  yield  more 
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structured  prograirts,  real-time  systems  often  cannot  tolerate  the  extra  process  context  switching 
overhead. 

10.  Advteory  information  interfaces  provide  additional  information  to  the  OS  file  system  so  that  the 
OS  can  optimize  file  access  (reduce  latervy.  prevers  fragmentatton,  speed  addressability)  for  real-time 
applications.  This  serves  to  improve  performance  and  eliminate  the  non-determinism  typicaHy  associated 
wth  UNIX  fie  access. 

1 1 .  POSIX  threads  provide  a  complete  API  set  for  lightweight  processes  that  can  coexist  with  the 
heavier  POSIX  process  model.  Threads  within  a  single  POSIX  process  share  a  considerable  amount  of 
state  information  (including  memory):  thus,  context  switching  among  threads  experiences  lower 
overhead,  and  interthread  ITC  can  take  advantage  of  the  inherent  shared  memory.  Additionaiy.  threads 
provide  a  second  level  of  concurrency  model  that  matches  quite  nicely  with  the  two  levels  implidt  in  the 
Ada  programming  language  (several  tightly  coupled  Ada  tasks  per  Ada  program,  several  loosely  coupled 
Ada  programs  per  system). 

12.  The  Spawn  process  creation  primitive  provides  an  enhancement  over  the  traditional  1003.1 
fork()  and  exec()  APIs  for  real-time  systems.  The  1003.1  interfaces  in^ly  not  only  the  existence  of  a  file 
system,  but  also  a  two  step  method  of  starting  a  new  process  which  forces  an  often  unnecessary 
duplication  of  an  existing  process.  Spawn  provides  the  more  or  less  conventional  real-time  practice  of 
"create  process”  with  a  single  interface. 

13.  Timeouts  for  Blocking  Services  adds  the  conventional  real-time  capabiiity  of  attaching  an 
upper  bound  to  the  amount  of  time  which  several  critical  real-time  interfaces  may  block  a  requestirrg 
process  or  thread.  This  capability  is  used  primarily  to  increase  the  robustness  of  real-time  applications  in 
fault  situations. 

14.  Execution  Time  Monitoring  provides  the  ability  for  a  process  or  thread  to  check  the  cumulative 
execution  time  of  itself  or  another  process  or  thread,  and  to  establish  CPU  time  limits.  Such  interfaces  are 
essential  in  deadline  driven  real-time  systems  to  ensure  that  all  processes  and/or  threads  are  given  fair 
opportunity  to  meet  their  deadlines. 

15.  Sporadic  Server  interfaces  complement  Priority  Scheduling  interfaces  in  real-time  systems 
driven  by  external  aperiodic  requests.  These  simplify  the  srhadulability  analysis  (as  in  rate  monotonic 
scheduling  theory)  of  such  a  real-time  system  because  the  aperiodic  processes  or  threads  to  be 
treated  as  H  they  were  periodic. 

16.  Device  Control  standardizes  the  format  of  interfaces  to  device  drivers  which  go  beyond  the 
1003.1  open/ciose/read/write/seek  interfaces.  Real-time  systems  typically  utilize  unique  devices  with 
unique  "out-of-band"  control  requirements.  UNIX  has  always  provided  an  ioctl()  interface  to  invoke  such 
control  actions  as  unloading  a  magnetic  tape  or  setting  the  baud  rate  of  a  communication  port.  Device 
Control  is  a  natural  extension  of  these  capabilities  to  general  control  requirements  for  arbitrary  devices 
(such  as  radar  or  analog-to-digital  converters).  It  does  not  attempt  to  define  actual  control  requirements, 
only  the  interfaces  necessary  to  pass  control  information. 

17.  Interrupt  Control  provides  standard  interlaces  for  connecting  architecture  and  hardware 
dependent  interrupts  to  application  code.  Real-time  applications  frequently  need  asynchronous 
notification  of  the  occurrence  of  some  hardware  generated  event.  Performance  is  often  an  issue,  so 
Intermpt  Control  addresses  performance  and  other  tradeofts  associated  with  d'lfterent  methods  of 
asynchronous  notification  (Note  that  POSIX  otherwise  supports  only  a  single  method  of  asynchronous 
event  notification,  the  Signal). 

18.  Typed  Memory  Allocation  adds  interfaces  to  POSIX  which  support  dynamic  memory  allocation. 
POSIX  had  deviously  deferred  all  memory  allocation  interfaces  to  the  ANSI  C  standard.  Given  the 
evolution  of  other  languages  which  require  dynamic  memory  allocation,  and  the  proliferation  of  real-time 
systems  which  utilize  several  types  or  partitions  of  memory  from  which  such  allocation  is  possible,  the 
ANSI  C  mallocO  interlace  is  no  longer  adequate. 
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4.2.2  Real  Time  in  NGCR  OS 

Although  POSIX  interfaces  differ  substantially  from  most  conventional  real-time  operating  systems 
used  heretofore  in  Navy  systems,  the  substantial  progress  achieved  by  1003.4  coupled  with  increased 
irxfustry  impetus  toward  real-time  UNIX  implementations  would  indicate  that  POSIX  will  eventually  be  an 
acceptable  OS  interface  for  all  but  the  smallest  and  most  time  critical  Navy  applications. 

Real-time  profiies  being  developed  by  Pi  003. 13  will  stress  the  need  for  high  performance  OS 
implementations  for  real-time  systems.  The  interfaces  themselves  cannot  generally  be  evaluated  with 
respect  to  performance  because  performance  e  a  characteristic  of  an  implementation,  not  an  interface. 
However,  ^rformance  metrics  are  beirig  developed  as  part  of  the  standards,  and  substantial  effort  has 
been  expended  to  ensure  that  the  real-time  interfaces  do  not  preclude  effcient  implementations.  Thus,  it 
is  reasonable  to  expect  that  the  Navy  will  be  able  to  purchase  good  real-time  operating  system 
implementations  compliant  with  the  POSIX  interface  standards.  This  means  that,  in  spite  of  the  fact  that 
POSIX  Interfaces  are  quite  unlike  those  found  in  conventional  real-time  operating  systems,  NGCR  OS 
based  on  POSIX  will  support  real-time  applications  once  real-time  programmers  understand  and  accept 
the  POSIX-ia<e  interfaces. 


4.2.3  NGCR/POSIX  Real-Time  Delta 

The  following  unfulfilled  requirements  are  especially  significant  to  real-time  applications  because 
missing  capabilities  prevent  a  fine  degree  of  control  over  the  performance  of  the  system  in  functions 
common  to  most  real-time  applications: 

1.21  Bounded  OS  Service  Times  and  Context  Switching 

6.3  File  Management  Scheduling 

7. 1  Device  Driver  Availability 

16.10  Monitor  Task's  Execution  Status  (Ada) 

16.17  Enable/Disable  Interrupts  (Ada) 


The  following  unfulfilled  requirements  are  especially  significant  to  multiprocessor  and  distrtxjted 
real-time  systems  because  of  the  lack  of  a  standardized  approach  to  handling  global  time: 

15.4  Selection  of  primary  reference  clock 

1 5.5  Locate  primary  reference  clock. 

The  following  unfulfilled  requirements  are  also  significant  to  real-time  systems  but  reflect 
capabilities  which  are  not  comrTX)n  to  all  real-time  systems  or  are  typically  out  of  the  mainstream  of  real-time 
processing. 


1.17  Error  conditions 

I . 23  Transaction  scheduling  infonnation 

5. 1  Event  and  error  receipt 

5.2  Event  and  error  distribution 

5.3  Event  and  error  management 

5.4  Event  and  error  logging 

10.2  Execution  history 

II. *  Reliability,  adaptability,  and  maintainability  (all) 

13.5  Transaction  scheduling  information. 

The  following  unfulfilled  requirements  may  have  some  bearing  on  the  performance  of  some  real¬ 
time  systems,  although  the  relationship  is  a  secondary  one: 

4. 1  Data  interchange  services 

9.2  Terminate  Process 
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9.11  Examine  piocess  status 
9.13  Save/restart  process 

12.3  Dyrtainic  memory  alocation  stfKl  deaUocation 

12.4  Dynanrtic  memory  protection 

12.5  Shared  memory  (as  unfuHiiled  -  for  code  segments) 

16.6  Restart  task  (Ada) 

16.15  Memory  allocation  and  deallocation  (Ada). 


4.3  FAULT-TOLERANT  SYSTEMS 

Because  many  of  the  Navy  systems  to  utilize  NGCR  OS  will  be  mission  critical,  the  OS  must 
support  the  ability  to  detect,  report,  isolate,  and  recover  from  any  foreseen  hardware  or  software  failure, 
thereby  ensuring  that  the  effects  of  such  a  failure  on  the  mission  are  minimal.  Fault  tolerance 
requirements  are  explicitly  seen  in  service  classes  5  (event  and  error  nrtanajjement)  artd  1 1  (reliability, 
adaptabiBty,  and  maintainability),  while  some  other  rer^irements  also  have  impllcatbns  ki  this  area. 


4.3.1  Fault  Tolerance  In  UNIX 

Unfortunately,  UNIX  systems  have  traditionally  had  poor  fault  tolerance.  Generally,  software  errors 
generated  by  an  application  and  some  hardware  errors  related  to  a  device  in  use  by  an  application  are 
reported  back  to  the  application  either  synchronously  (via  error  return  codes  and  the  ‘‘ermo”  system 
variable)  or  asynchronously  (via  a  signal).  The  OS  assumes  no  further  role  in  the  processing  or  logging  of 
such  errors,  nor  are  there  any  services  that  assist  in  the  recovery  from  errors.  Furthermore,  software  errors 
detected  within  the  UNIX  kernel,  and  many  hardware  errors,  cause  the  OS  to  simply  give  up.  For  example, 
many  UNIX  systems  will  not  configure  themselves  around  failed  memory  but  instead  inform  an  operator 
and  halt,  awaiting  reboot  of  the  system  or  they  reboot  themselves  automatically  (a  process  that  takes  from 
one  to  many  minutes).  In  these  cases,  all  user  aii^lications  die  in  their  tracks  with  no  potential  to  recover 
anything  unless  the  application  has  generated  its  own  checkpoints.  Curiously,  in  these  circumstances, 
the  error  is  frequently  logged  in  a  file  accessible  to  the  system  administrator. 

UNIX  behaves  this  way  because  its  typical  users  have  been  mnning  applications  in  a  time-sharing 
environmerrt  where  centralized  error  handling  and  dynamic  recovery  are  not  the  rule,  but  where  having  a 
system  administrator  in  the  loop  is. 


4.3.2  Fault  Tolerance  In  POSIX 

There  had  previously  been  little  effort  in  the  POSIX  community  to  standardize  fault  tolerance 
related  interfaces.  This  issue  was  generally  considered  out  of  scope.  For  example,  a  significant  portion  of 
the  1003.4  working  group  membership  had  been  opposed  to  providing  timeouts  on  biocking  services 
because  they  cant  imagine  that  software  bugs  end  up  in  fielded  systems.  Recently,  the  hard  real-time 
contingent  of  that  working  group  has  pushed  for  the  kirxls  of  fault  tolerant  capabilities  that  provide  the 
characteristic  robustness  of  mission-critical  real-time  systems. 

OSSWG  has  led  a  Fault  Management  and  Administration  study  group  within  POSIX  over  the  past 
two  years.  While  this  group  had  initially  confirmed  that  existing  practice  in  fault  tolerant  operating  systems 
is  not  mature  ertough  to  begin  a  standardization  effort  immediately,  they  have  nonetheless  brought  this 
concern  to  the  for^ront.  The  group  continues  to  work  toward  standardized  Fault  Management  and 
Administration  interfaces  based  on  proposals  by  several  industry  groups  including  UNIX  International  and 
the  Open  Software  Foundation. 
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4.3.3  Fault  Tolerance  In  NGCR  OS 

NQCR  OS  requirements  specify  centralized  facilities  for  receipt,  coordination,  distribution, 
delivery,  and  losing  of  error  events,  whether  those  events  are  detected  by  hardware  or  software, 
whether  they  indicate  a  hardware  or  software  fault,  and  whether  the  fauR  occurs  wRhin  the  application  or 
the  operating  system.  The  OS  is  expected  to  collect  and  retain  as  much  information  as  possible  about  a 
fault  that  has  occurred  and  provide  access  to  this  information  to  an  application  (not  just  a  system 
administrator).  This  applies  to  fauRs  detected  asynchronously,  as  well  as  to  fauRs  discovered  by 
application  inRiated  hardware  diagnostic  tests.  For  transient  fauRs,  the  OS  must  be  configurable  with 
thresholds  that  establish  the  tolerance  level  for  errors.  Isolation  of  fauRs  to  a  system  cornponent  must  be 
supported,  and  the  OS  must  be  able  to  take  predetermined  actions  based  on  fauR  severity.  URimately, 
the  OS  must  support  reconfiguration  of  Rs  own  and  application  resources  when  one  or  several 
components  of  the  system  have  failed,  or  upon  application  request. 


4.3.4  NGCR/POSIX  Fault  Tolerance  Delta 

POSIX  and  UNIX  compliant  systems  today  provide  virtually  none  of  the  required  support. 
ARhough  R  is  not  r^uired  for  many  Navy  systems,  the  NGCR  OS  interface  will  have  to  augment  POSIX 
substantially  to  achieve  a  fauR  tolerance  level  acceptable  to  some  mission  critical  Navy  profiles.  The  most 
lately  route  to  this  goal  is  by  closely  following  the  activRies  of  UNIX  International,  OSF,  and  X3T8  in  these 
areas.  As  the  concepts  being  explored  by  these  groups  become  more  well  defined,  either  de-facto 
industry  standards  will  emerge  or  R  will  become  appropriate  to  reconsider  introduction  of  a  POSIX  PAR  to 
bring  such  de-facto  fauH  tolerance  interfaces  into  POSIX  scope. 


4.4  SECURITY 

As  stated  in  section  3.3,  aRhough  Pl003.1e  and  P1003.2C  meet  or  support  most  of  the  OSSWG 
security  requirements,  further  guidance  is  provided  and  required  by  the  TCSEC  and  SECNAV  Instruction 
5239.2  "information  SecurRy  Instruction."  The  subject  of  the  TCSEC  and  Rs  interrelationship  wRh  the 
NGCR  standards  for  security  raises  several  issues: 

1.  The  relationship  between  the  Pi  003.  le/PI 003.2c  and  the  TCSEC  standard. 

2.  The  integration  of  corrvTKin  security-related  features  between  various  standards  (e.g., 

NGCR,  DoO,  ISO)  and  which  standard  takes  precedence. 

3.  The  integration  of  common  functions  and  features  as  the  resuR  of  using  two  or  more 
standards-based  trusted  commercial-off-the-sheR  (COTS)  products  when  they  become  avaiiabie. 

This  must  also  consider  the  integration  of  different  TCSEC  class  COTS  products  or  systems. 

Navy  acquisition  programs  must  comply  wRh  DoD  directives  and  the  SECNAV  instruction.  Both 
recommend  the  TCSEC  standard  to  develop  security  requirements  for  acquisition  programs.  The  TCSEC 
is  a  collection  of  security  crReria  organized  into  classes.  In  most  acquisitions,  requirements  may  be 
specified  from  different  TCSEC  classes  based  on  the  criticality  of  the  mission  and  the  level  of  physical, 
procedural,  operational,  and  communication  securRy  at  the  operational  sites.  For  some  specRic 
acquisRion  programs  or  missions,  the  requirements  cited  for  a  particular  TCSEC  class  may  not  all  apply. 
NGCR  OSSWG  has  reviewed  PI 003.1  e  and  PI  003.2c  and  found  them  compatible  wRh  the  TCSEC 
criteria.  (Note:  In  annex  B  of  Pi  003.1  e,  the  POSIX  security  subcommRtee  gives  Rs  reasons  for  choosing 
the  TCSEC  as  the  main  source  of  security  criteria.)  As  R  defines  each  of  the  functions  wRhin  each 
category  of  the  interface  standard  (i.e.,  DAC,  MAC,  Privileges,  AudR,  Information  Labels),  P1003.1e  and 
P1 003.2c  attempt  to  ensure  that  the  securRy  portion  of  the  standards  does  not  preclude  meeting  the 
higher  class  TCSEC  systems.  ARhough  R  is  not  explicRIy  cRed  in  P1003.1e  or  P1 003.2c,  R  is  implied  that 
to  qualRy  as  a  TCSEC  class  system  the  P1003.1e  and  Pl003.2c  interface  requirements  must  be 
develop^  in  conjunction  wRh  the  corresponding  criteria  stated  in  the  TCSEC. 
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The  integration  of  common  securtty-reiated  features  between  the  various  standards  is  norv-trivial. 
Lkewise,  the  use  of  trusted  portable  application  software  between  systerrrs  built  on  different  hardware 
platforms  having  a  simHar  Pi^lX  interface  may  require  further  examination  of  the  applic^ion  software.  In 
either  case  when  combinations  of  NGCR  standards  or  standards-based  COTS  products  are  used,  further 
system  level  analysis  is  required  to  identtfy,  address,  and  resolve  the  si^icant  integration  issues. 

An  example  which  illustrates  both  issues  addressed  above  is  labeling.  POSIX  treats  a  label  as  an 
unstructured,  undefined  opaque  object  for  portabiUty  purposes.  This  allows  each  vendor  or  developer  of 
trusted  application  software  who  uses  the  P1003.1e  and  P1003.2c  standards  to  define  the  internal 
structure  of  the  label.  From  a  standalone,  homogeneous  system  perspective,  this  may  not  cause 
significant  problems  for  Navy  system  engineers.  However  in  a  distributed,  heterogerreous  system  when 
several  NGCR  standards  and/or  standards-based  tnjsted  application  produds  are  inte^ated,  addittonal 
requiremerrts  may  be  necessary  to  define  a  common  label  format.  This  may  be  especially  the  case  when 
trusted  application  programs  are  created  to  perform  label  transformations  for  mission-critical  systems  and 
such  software  must  be  totally  correct.  Such  trusted  application  programs  in  general  may  not  be 
transferable  among  heterogeneous  POSIX-based  systems. 

The  security  requirements  and  the  implementation  of  these  requirements  should  always  be 
viewed  in  terms  of  the  TCSEC.  P1003.le  and  P1003.2C  are  interface  standards  that  do  not  preclude 
meeting  the  TCSEC  class  requirements.  However.  PI  003.1  e  and  P1 003.2c  in  themselves,  being 
interface-related  standards,  cannot  address  all  the  operating  system  security  requirements.  The  desi^ 
and  implementation  of  the  P1 003.1  e  and  PI  003.2c  standards  must  be  used  in  conjunction  wfih 
requirements  from  the  TCSEC  classes  to  provide  a  well-defined  system  and  a  potentially  ceriifiabie  secure 
product. 


4.5  HETEROGENEITY 

It  has  been  a  goal  of  the  NGCR  OS  to  support  heterogeneous  systems;  that  is,  the  same  OS 
interface  must  not  only  support  a  variety  of  processor  architectures,  but  it  must  allow  dissimilar  processors 
to  cooperate  as  part  of  a  larger  system.  This  can  take  the  form  of  heterogeneous  processors  on  the  same 
backplane  (Futurebus+)  or  more  commonly,  heterogeneous  processor  types  at  d'rfferent  nodes  of  a 
distributed  system. 


4.5.1  Heterogeneity  in  UNIX 

Today's  UNIX  systems  support  heterogeneity  largely  through  the  use  of  network  services  that 
provide  commonality  of  function  and  information  representation  anwng  different  processor  types  (some 
njnning  different  vendors'  UNIX)  that  share  a  common  network  medium  and  protocol  (e.g.,  ethemet). 
Examples  are  network  file  system  (NFS)  and  remote  shell  (rsh)  cap^ilities.  Such  services  typically  do  not 
attempt  to  solve  data  Interchange  format  problems  (word  size,  floati^  point  format,  endian-ness),  leaving 
that  as  an  exercise  for  the  user;  however,  they  do  allow  applications  to  work  together  fairly  well  in  a 
heterogeneous  distributed  environment. 

Few  UNIX  systems  today  support  heterogeneity  on  the  same  backplane,  simply  because  that  is 
not  a  typical  configuration.  Notable  exceptions  such  as  V\find  River's  VxWorks  do  allow  host  (e.g..  Sun 
workstation)  and  target  (e.g.,  Mizar  SPARC/VME-based  real-time  subsystem)  to  share  a  common 
backplane  and  memory. 


4.5.2  Heterogeneity  in  POSIX 

The  POSIX  standards  effort  is  a  giant  step  forward  in  supporting  heterogeneity,  since  it  attempts 
to  standardize  not  only  the  basic  interfaces  (thus  ensuring  source  code  portability),  but  also  the 
distributed  services  (thus  allowing  for  universal  interoperability,  at  least  across  a  network).  The  issue  of 
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heterogeneity  in  a  nrultiprocessor  (dissimitar  processors  sharing  memory)  is  not  addressed  by  POSIX 
except  in  the  distributed  context. 


4.5.3  Heterogeneity  in  NGCR  OS 

Hete^eneity  is  not  called  out  in  any  specific  NGCR  OS  requirement  (though  service  class  4,  data 
interchange  interfaces,  certainly  hints  at  it).  This  is  because  the  ability  of  one  inpiementation  of  an 
operating  system  to  work  harmoniously  with  another  implementation  is  largely  an  implementation  issue. 
For  example,  if  two  implementations  of  a  file  system  namespace  use  the  standardized  interface  but  two 
different  character  sets,  then  the  ability  to  share  namespace  information  between  these  implementations 
is  severely  hampered.  The  OSSWG  should  (1)  attempt  to  identify  those  POSIX  implementation 
dependencies  that  are  detrimental  to  heterogeneity  and  (2)  create  an  “implementor's  guide*  to  promote 
increased  interoperability. 


4.5.4  NGCR/POSIX  Heterogeneity  Delta 

Although  the  POSIX  standardization  effort  and  POSIX  distribution  standards  are  a  strong  positive 
step  for  heterogeneous  systems,  the  POSIX  motive  is  source  code  portability,  not  interoperability.  Thus, 
it  is  unlikely  that  initial  implementations  of  POSIX-compliant  systems  will  work  trouble-free  in  a 
heterogeneous  environment.  The  POSIX  (and  thus,  the  NGCR  OSSWG)  focus  on  APIs  simply  does  not 
address  standardization  of  certain  system  interfaces  (particularly  OS-to-OS  interfaces  and  global  resource 
management). 


4.6  ADA 

The  Ada  programming  ian^age  is  not  only  the  mandated  DoO  standard  (and  thus  Navy  standard) 
programming  language,  but  is  an  international  standard  for  large  scale,  long-lived,  reliable  applications. 
The  Ada  language  is  somewhat  unique  in  that  it  defines  within  the  language  a  number  of  operations  that 
heretofore  were  considered  to  be  in  the  domain  of  the  target  operating  system,  but  that  ultimately  must  be 
supported  by  an  operating  system  component.  Some  Ada  compilers  are  targeted  to  the  bare  machine; 
that  is,  the  compiler  vendor  supplies  the  full  underlying  operating  system.  Other  Ada  compilers  are 
targeted  to  a  machine  already  mnning  particular  operating  systems;  in  this  case,  the  Ada  vendor's  run-time 
support  package  and/or  the  generated  code  itself  interfaces  with  an  operating  system  supplied  by 
another  vendor  (typically,  the  computer  vendor)  whenever  operating  system  sen/ices  are  required. 

The  Ada  language  also,  like  other  language  standards,  specifies  certain  required  library  packages 
that  must  rely  on  operating  system  services  for  support. 

Examples  of  operating  system  senrices  implicit  in  the  Ada  language  are  the  Ada  tasking  model 
(entry  call,  accept,  select,  etc.),  the  delay  statement,  the  "new"  allocator,  and  various  Ada  exceptions  that 
may  originate  as  machine-specific  hardware  interrupts  (Numeric.Error,  for  example).  Examples  of  Ada 
library  packages  that  require  operating  system  support  are  Text_IO,  Low_LevelJO,  IO_Exceptions, 
Unchecked_Deallocation,  and  Calendar. 


4.6.1  Ada  in  UNIX 

UNIX-based  systems  have  been  popular  platforms  for  Ada  language  implementations,  but  there 
has  been  a  great  deal  of  misunderstanding  and  controversy  surrounding  such  implementations.  UNIX 
implementations  have  typically  been  a  poor  fit  for  the  services  required  by  the  Ada  language.  For 
example,  UNIX  kernels  have  no  schedulable  entity  that  maps  to  an  Ada  task,  so  UNIX-based  Ada 
implementations  have  usually  provided  a  library  level  scheduler  for  Ada  tasks.  This  approach  has  two 
drawbacks.  First,  whenever  such  an  Ada  task  must  invoke  an  operating  system  sen/ice  that  blocks,  all  the 
Ada  tasks  in  the  Ada  program  are  blocked  instead  of  only  the  one  requiring  the  blocking  service;  second. 
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the  timely  execution  of  ttie  Ada  tasks  cannot  be  guaranteed  because  the  UNIX  process  in  whk^  the  Ada 
tasks  live  itself  competes  for  the  CPU  via  a  different  scheduler  (the  UNIX  process  scheduler).  Anr^her 
example  of  a  poor  fit  is  the  various  Ada  timing  services.  Because  UNIX  provides  timing  senrices  only  at  1- 
second  resolution,  Ada  implementations  have  been  forced  to  use  some  fairly  naocurate  and  inefficient 
polling  methods  of  timing.  Even  the  Ada  line  and  record-oriented  I/O  models  are  poorly  supported  by  ttie 
UNIX  byte-stream  I/O  model. 

Generally,  the  outcome  of  this  poor  fit  is  that  portable  Ada  programs  don't  work  exactly  as  might  be 
expected,  either  from  the  Ada  perspective  or  from  the  UNIX  perspective.  Vendors,  realizing  this,  typically 
provide  additional  nonstandard  libraries  to  allow  Ada  programs  to  be  more  'UNIX  late.”  Unfortunately,  this 
does  very  little  for  portability,  even  from  one  Ada  compiler  implementation  to  another  on  the  same  UNIX 
operating  system. 


4.6.2  Ada  in  POSIX 

POSIX  has  been  supporting  Ada  through  the  1003.5  working  group,  the  product  of  which  is  to  be 
a  standard  that  makes  the  functionality  of  ISO/IEC  9945-1  ;1990  (1003.1)  available  to  the  Ada  programmer. 
The  PI  003.20  working  group  is  doing  the  same  for  the  evolving  real-time  extensions  (1003.4,  1003.4a, 
and  1003.4b). 

It  is  important  to  note  what  1003.5  does  and  does  not  atterr^t  to  do.  In  particular,  1003.5 
provides  an  Ada  language  binding  to  POSIX  interfaces;  i.e.,  an  Ada-like  way  to  invoke  POSIX  services,  it 
does  NOT  attempt  to  define  POSIX  interfaces  suitabto  for  supporting  all  the  Ada  run-time  capabilities. 
Generally  speaking,  the  POSIX  community  seems  to  feel  that  the  latter  is  not  in  its  sr^e.  Nonetheless, 
recent  activity  in  1003.4  (i.e.,  concern  that  Pthreads  be  usable  as  Ada  tasks)  indicates  that  there  is 
increasing  sentiment  toward  supporting  POSIX  in  the  Ada  run-time  environment.  The  1003.5  working 
group  is  currently  debating  the  inclusion  or  exclusion  of  Ada  bindings  to  real-time  interfaces  that  would 
conflict  with  capabilities  of  the  Ada  mn-time,  or  that  would  allow  an  Ada  run-time  environment  to  be  written 
in  Ada. 


4.6.3  Ada  in  NGCR  OS 

It  is  essential  that  NGCR  OS  support  not  only  an  Ada  language  binding  to  all  defined  OS 
interfaces,  but  also  the  implicit  interfaces  required  by  the  Ada  ron-time  and  the  standard  Ada  library 
packages.  These  latter  requirements  are  pretty  much  detailed  in  OSSWG  requirements  for  service  class 
16,  while  the  language  binding  requirements  appear  in  service  class  1. 

In  cases  where  an  OSSWG  requirement  is  satisfied  directly  within  the  language  or  from  a  standard 
Ada  library  package,  and  an  explicit  binding  to  the  underlying  service  interface  adds  no  functionality,  the 
explicit  binding  is  not  necessary.  For  example,  the  POSIX  "sleep"  interface  adds  no  functionality  over  and 
above  the  Ada  "delay"  statement  and  it  is  therefore  unnecessary  to  have  an  Ada  binding  to  the  OS 
"sleep."  Also,  where  an  OS  interface  exists  wholly  to  support  a  different  language  binding,  an  Ada 
binding  makes  no  sense  (e.g.,  the  1003.4a  C  interface  *pthread_equar  exists  because  comparison  of 
opaque  types  using  the  C  operator  is  invalid  for  pointer  implementations  of  such  types). 

In  support  of  the  goals  of  application  portability  and  reusability,  NGCR  applications  must  avoid  the 
practice  of  substituting  nonstandard  language  constructs  and  library  packages  for  standard  Ada 
capabilities.  Toward  this  goal,  it  is  essential  that  the  NGCR  OS  implementations  support  standard  Ada 
capabilities  with  very  high  performance,  since  performance  requirements  of  real-time  systems  often  take 
precedence  over  software  engineering  goals.  Hopefully,  as  Ada  matures  into  Ada-9X,  new  standard 
capabilities  will  be  added  to  compensate  for  some  of  the  architecture  and  OS  dependent  problems  that 
have  previously  forced  use  of  nonstandard  interfaces. 
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4.6.4  NGCR/POSIX  Ada  Delta 

The  1003.5  woiking  group,  in  its  process  of  drafting  Pi 003.20,  has  started  debating,  and  will 
continue  to  debate,  such  issues  as  providing  Ada  bindings  to  POSIX  interfaces  that  duplicate  or  confttct 
with  Ada  run-time  features,  and  providing  support  for  Ada  run-time  environments  written  in  Ada.  Once 
such  decisions  have  been  made,  the  exact  relationship  between  POSIX  and  Ada  will  be  more  weH 
defined.  POSIX  1003.1, 1003.4,  P1003.4a,  and  P1003.4b  certainly  appear  at  this  time  to  support  Ada- 
83  fairly  completely  and,  assuming  no  highly  unusual  policy  is  forthcoming  from  the  1003.5  working 
group,  the  delta  appears  small. 
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5.  CONCLUSIONS 


This  document  has  carefully  analyzed  each  NGCR  OSSWG  interface  requirement  (except  for  the 
very  general  requirements  in  Service  Class  1)  as  it  relates  to  the  POSIX  standardization  effort.  Of  the  155 
OSSWG  requirements  analyzed,  99  are  directly  met  by  the  existing  POSIX  interfaces;  Section  3 
documents  this  mapping.  Of  the  56  remaining  requirements,  44  have  been  classified  as  significant 
unfulfilled  requirements.  The  remaining  12  have  been,  or  are  being  re-evaluated  or  re-formulated  in  a 
manner  more  in  keeping  with  a  POSIX  philosophy;  these  will  ultimately  either  become  met  requirements, 
or  be  dropped  entirely  as  OSSWG  requirements. 

The  44  significant  unfulfilled  requirements  generally  fall  into  one  of  three  classifications:  those 
that  are  nearly  met  by  POSIX  with  the  exception  of  minor  details  (13),  those  that  clearly  belong  within  the 
POSIX  framewor1<  but  have  not  yet  baen  addressed  by  POSIX  (14),  and  those  which  are  outside  the 
scope  of  the  existing  POSIX  working  groups  (17).  This  "magnitude  of  delta"  for  each  requirement  is  more 
significant  than  the  actual  count  of  unfulfilled  requirements.  When  analyzed  by  service  class,  there  are 
only  a  few  trends  (primarily  the  lack  of  POSIX  support  for  service  classes  5  and  11);  but  when  the 
requirements  are  classified  by  importance  to  the  "Big  6"  technology  areas,  as  is  done  in  Section  4,  the 
relative  magnitudes  of  delta  becomes  clear:  POSIX  is  moving  in  a  positive  direction  in  the  areas  of  Real- 
Time  Systems,  Security,  and  Ada,  with  only  follow-up  work  required  to  satisfy  most  related  OSSWG 
requirements;  while  the  POSIX  framework  currently  addresses  areas  of  Distributed  Systems  and 
Heterogeneity,  there  is  substantial  additional  work  required  to  bring  these  up  to  OSSWG  standards;  and 
finally  the  Fault  Tolerance  area  has  only  recently  been  broached  by  POSIX  through  the  OSSWG  initiated 
Fault  Management  and  Administration  study  group  and  its  pending  POSIX  Services  for  Reliable,  Available, 
and  Serviceable  Systems  project. 

In  the  strategy  analyses  of  Section  3,  it  was  found  that  many  OSSWG  requirements  would  be 
best  met  by  working  within  the  POSIX  working  groups  and  balloting  groups  to  ensure  that  existing 
capabilities  are  extended  or  tuned,  and  that  the  necessary  new  capabilities  are  added;  indeed  this  method 
has  been  in  use  since  NGCR  OSSWG  became  active  in  the  POSIX  activities,  and  substantial  progress  has 
already  been  observed,  especially  in  the  real  time  and  networking  areas.  Over  half  of  the  significant 
unfulfilled  requirements  suggest  this  approach,  and  if  the  POSIX  Services  for  Reliable,  Available,  and 
Serviceable  Systems  PAR  is  approved,  virtually  all  of  these  requirements  can  be  ultimately  realized  within 
the  POSIX  framework.  Since  it  has  always  been  an  OSSWG  goal  for  the  OSIF  to  be  fully  under  the  purview 
of  a  single  standards  body,  this  is  very  encouraging  progress  indeed. 

It  was  not  always  the  case  that  this  many  requirements  had  a  "home"  within  POSIX.  First,  OSSWG 
initiated  the  Real  Time  Distributed  Systems  Communication  (1003  21)  project  which  has  completed  its 
requirements  analysis  process  and  has  begun  drafting  a  standard  ich  will  meet  most  of  the  unfulfilled 
OSSWG  networking  requirements.  Second,  a  Distributed  Security  (1003.22)  project  was  approved  to 
address  the  unfulfilled  security  requirements  and  how  the  POSIX  security  interfaces  will  support 
distributed  systems.  Third,  although  the  Fault  Management  and  Administration  Study  Group  had 
concluded  that  it  was  inappropriate  for  POSIX  to  standardize  on  Fault  Tolerance  interfaces  a  year  ago,  that 
OSSWG  initiated  group  continues  to  gather  Industry  support,  has  closely  followed  the  evolution  of  various 
non-POSIX  efforts  in  the  Fault  Tolerance  arena  (e.g.  UNIX  International,  OSF,  X3T8),  and  expects  to 
become  a  fully  recognized  POSIX  project  in  the  near  future.  These  three  relatively  new  efforts  have 
provided  the  foundation  for  many  of  the  most  difficult  delta  resolutions.  Finally,  recommendations  have 
been  made  to  attach  to  other  existing  and  evolving  standards  outside  the  POSIX  framework  where 
appropriate  (e.g.  P1256/OBIOS,  ANSI/RPS,  ASN.1,  Network  Time  Protocol,  and  the  Dwight  Wilcox 
Distributed  Realtime  Clock  Synchronization  approach),  but  only  if  and  when  OSSWG  has  exhausted  ail 
POSIX  resolution  alternatives. 

This  document  defines  much  of  the  remaining  work  ahead  for  the  NGCR  OSSWG,  especially  as 
Ts  membeiS  debate  and  ballot  the  various  existing  POSIX  draft  standards  and  contribute  to  new  ones.  It 
u!so  serves  as  an  important  basis  for  the  ultimate  product  of  the  NGCR  OSSWG,  a  military  handbook  or 
technical  specification  for  the  NGCR  OSIP . 
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This  document  recommends  a  number  of  OSSWG  requirements  be  re-evaluated.  Changes  to 
the  requirements  in  the  OCD  may  result  from  this  re-evaluation  process,  which  in  turn  may  cause  some 
change  of  deltas  in  the  next  Delta  Document  revision.  In  addition  to  specifically  recommended  re- 
evaluations,  OSSWG  has  two  ^neral  concerns  about  the  requirements;  First,  OSSWG  had  purposely 
avoided  addressing  the  semantics  of  each  requiremertf  in  a  distributed  computing  environment  because 
of  the  relative  immaturity  of  distributed  services  within  POSIX;  that  area  has  matured  substantially,  and  the 
time  has  come  to  explicitly  split  each  requirement  (where  it  makes  sense)  into  its  non-distributed  and  its 
distributed  context.  Second,  certain  requirements  have  been  perceived  as  dictatir^  an  implementation  to 
meet  a  requirement  rather  than  stating  the  tnie  requirement  and  giving  the  operating  system  the  freedom 
to  meet  it  in  the  best  way  possible  in  a  given  inplementation;  requirements  such  as  Write  Contiguous  File 
(6.20)  and  Unacknowledged  Connection  Oriented  Service  (8.4)  are  examples.  Therefore,  OSSWG 
recommends  a  thorough  review  of  the  OCD  requirements,  addressing  these  two  overall  concerns,  prior  to 
the  next  Delta  Document  revision. 

This  Version  4  of  the  Delta  Document  is  not  the  final  version.  This  is  a  living  document  and  will 
change  as  (1 )  POSIX  evolves,  and  (2)  the  OSSWG  is  able  to  develop  new  methods  of  satisfying  the 
remaining  deltas.  We  intend  to  update  this  document  yearly,  at  least  until  completion  of  the  military 
handbook  or  technical  specification. 
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APPENDIX  A 

DELTA  SUMMARY  AND  CROSS  REFERENCES 


The  table  on  the  following  pages  lists,  tor  each  OSSWG  requirement  (except  the  general 
requirerrtenls  of  service  class  1)  references  to  all  POSIX  interfaces  which  OSSWG  believes  fully  or  partially 
fulfill  the  requirement.  The  POSIX  document  number,  paragraph  number(s),  and  a  brief  description  of  the 
pertinent  interfaces  and/or  capabilities  is  provided. 

In  addition,  each  unfulfilled  requirement  is  coded  with  a  rating  indicating  its  significance  to  the 
overall  NGCR  OS  interface  standardization  effort:  A  rating  of  "a”  indicates  that  standardization  of  interfaces 
which  meet  the  requirement  is  essential:  a  rating  of  *b*  indicates  that  standardization  of  interfaces  which 
meet  the  requirement  is  highly  desirable;  a  rating  of  "C  indicates  that  fulfilling  the  requirement  can  be 
deferred  to  a  later  date;  a  rating  of  "cT  indicates  that  the  OSSWG  should  re-evaluate  the  need  for 
standardized  interfaces  fulfilling  the  requirement. 

Finally,  for  each  unfulfilled  requirement,  the  OSSWG  recommendations  are  summarized. 
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DELTA  SUMMARY  AND  CROSS  REFERENCES  (Cont'd) 
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